itimpi

According to your diagnostics there are problems with your cache drive so it is not mounting.    That would explain your symptoms.

A share gets automatically created whenever a top level folder is created on a drive.    It is almost certainly due to you having a docker container with that mapped.

The boot USB drive does not count.   Any other attached storage device counts regardless of how it is connected.

To emphasise the point there is no requirement for both parity drives to be the same size as long as they are larger or the same size as the largest data drive.

Definitely sounds like major problems on the flash drive.   I suspect it Is failing but the only way to be sure will be to try rewriting it.   The config folder should only be a few hundred Mb so there is definitely something seriously wrong.
 
Your disk configuration is in the config/super.dat file so it looks like you may have managed to copy that OK.  Hard to be certain as it is not human readable.   You also seem to have copied the .key licence file OK?   Looks like most of the other default configuration files are gone.
 
Sounds like you have little choice except to try creating a new flash drive and reconfiguring your Unraid server.   Copying across the super.dat file (if it is not corrupt) and the licence .key file will hopefully slightly reduce the amount of re-configuration needed.
 
You want to make sure that going forward you have a backup of the flash drive so you can quickly recover if a flash drive fails.  You can take a manual backup of your flash drive at any time by clicking on it on the Main tab and selecting the Backup option.    You can have automated backups to the cloud on Limetech servers if you install the MyServers plugin or locally using the CA Appdata backup plugin.

Looks like you might have a NIC that is currently being blacklisted as described in the 6.10.2 Release Notes.  As far as know there is no Dell server reported so fa that suffers from the data corruption issue so it should be safe to take the steps described there to un-blacklist the NIC. An alternative would be to run the earlier 6.9.2 release.

It sounds like you need to use the Parity Swap procedure.

My suggestion would be to first add the parity2 drive and build parity on that and then replace the parity1 drive.   That means that you have parity protection during the process.  
 
In theory you could do both at the same time but if a data drive failed while doing that you could end up with data loss.

Unfortunately not (at least as far as I know).

You DO have to have at least 1 drive in the main array to keep Unraid happy, but for a Use Case like yours it could be something inconsequential like a flash drive.
 
A point to remember is that you still need to have backups of anything important or irreplaceable.  Having a redundant pool is not enough to guarantee that nothing will go wrong that could cause data loss as there are lots of ways to lose data other than simple drive failure.   Your approach needs to take that into account.

one begins to see a pattern after a while to certain types of error  
 
If no hardware is being passed through then there is no reason not to start the VM.

You left out the key step - Apply.   The Done button is equivalent to a Cancel.

Your syslog shows continual resets on the 8TB drives - in particular disk6 and disk7.  You should carefully check SATA and Power cabling to those drives.  
Since you have just added some extra drives are you sure the power supply can handle them?

Email limtech using the contact link at the bottom each forum page.

According to your diagnostics your docker.img file is corrupt.    It probably needs to be recreated and the docker applications reinstalled.
 
I notice that you have this file set to be 200GB - is there any reason you have it set to such a large value.    The 20GB default size is fine for most users and 30GB enough for the more extreme users. Have you had trouble with it filling up - if so this suggest misconfigured container(s) that is writing internally to the container rather than to externally mapped storage.

Have you read the 6.10.2 release notes and the issues around the tg3 NIC driver?   You may need to take the steps to unblacklist that driver to get your network working if you think your hardware is not one being affected by the tg3 issue.

That tends to indicate a problem reading a file off the flash drive.    You might want to try following the procedure here to see if it helps.

Have you checked to see if the EFI folder on the flash drive has trailing tilde character?   If so you need to remove this to enable UEFI boot.

You click on the pool on the Main tab; scroll down to the Balance section; select the Single option from the dropdown and then start the Balance as described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

That looks as if no major corruption was found.
You need to run without the -n option if you want anything to be fixed, and if it asks for it add the -L option.
 
Restarting in normal mode should mean the drive then mounts OK.   Look to see if you now have a lost+found folder - if not all data should be intact.

it looks like disk have slightly different ways of reporting their serial numbers under 6.10.0 on your system.

You should be able to:
Use Tools->New Config and use the option to keep all assignments return to the Main tab and correct all drives to have their new version of the serial numbers tick the “Parity is Already Valid” checkbox start the array and with any luck everything will now come up as normal.

Just realised that I did not answer this bit.  In this case the time to rebuild a drive is determined by the size of the drive being rebuilt (at the same 2-3TB per hour estimate as used for the parity build) so if the disks are smaller than the parity drives it does not take as long.
 
Another way to look at it is that both processes involve writing to every sector on a drive so how quickly that can be done is the determining factor.
 

I assume the disk that should be disk3 is the one with WSD0QVWE as its serial? My guess would be that you disturbed its connection when adding the drives you now want as Unassigned drives.   It is showing up OK in the SMART reports and it looks OK there.
 
Does Unraid show that disk3 is currently being emulated?   If so check that the emulated disk has the content you expect as the process for getting it back into the array involves rebuilding the drive with the contents that are shown as present on the emulated disk3 by stopping the array; assigning the disk as disk3; and restarting the array to rebuild the physical disk3 to match the emulated one.
 
if the emulated disk3 does NOT show the expected content then do not rebuild but post back here for advice.

If the vdisks were in the 'domains' share then this is set with
shareUseCache="prefer" which meant you WANT the files on the cache, and if mover finds them on the array it should move them to the cache (space permitting).
 
You also do not have a Minimum free Space set for the cache, and it is a good idea to have this set to be at last the size of largest file you expect to copy there in normal use at it is not unusual for corruption to occur if is gets completely full.
 
 

Have you tried clearing cookies/cache in your browser (or using incognito mode).