itimpi

That will be because when you make that sort of change Unraid restarts Samba so any transfer in progress at the time gets aborted.     There has been discussion about changing this to just tell Samba to reread its configuration file but as far as I know that has not happened and I do not know of any immediate plans to make such a change.

You can rebuild each disk in turn if that is more convenient.   After the first rebuild succeeds then the array will be back in a protected state.

If when you got the original failure once you had described your problem and posted diagnostics so we could confirm there was nothing else obviously wrong we could have given you the steps to get Unraid to accept the original parity disk so that you could then probably get an error-free rebuild of disk3.
 
 In principle it is a good idea to ask for help before letting Unraid do anything you are not sure about.

This suggests a hardware issue.   I would carefully check your cooling (especially the CPU fan) in case it is thermally related.   Another possibility since you say you recently added new drives would be that the PSU is overloading trying to handle the additional hardware.
 
As was mentioned the syslog server should allow a software trigger to be eliminated.
 
Regarding unclean shutdowns you may find this section of the online documentation to be helpful.

That shows the extended test failed, so the disk should be replaced.

In theory one could do clever things by going under the hood and manipulating the underlying Linux file/folder level permissions, but in practice for most purposes file security and share level security end up being the same thing when using Unraid.

What are the sizes of your data drive and the parity drive?  Once the parity build has gone past the size of a data drive then that data drive can be spun down as it is no longer needed.

Mover never moves files between pools, only to/from a designated pool and the array.
 
you either need to do such a move manually or do it in 2 stages - 1 to get files off old cache onto array and then a second one to get files off the array and onto the new cache drive

It is not the time to calculate the parity that is the issue, but the disk rotations involved.    This is described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Did you redo any hardware pass throughs to the VM after plugging in the LSI card?    It is highly likely that the hardware IDs changed after the LSI card was plugged in.

Was the disk disabled (had a red ‘x’ showing on the main tab)?  If it was then the disk would have been emulated and the file system check run against the emulated disk, whereas if not it was against the real disk.   The reason I ask is that the rebuild process simply makes a physical drive correspond to the emulated one (including any file system corruption).   If the drive was NOT disabled then it could be worth running the check again this time against the emulated drive to see what that reports.
 
Do you have a spare disk available to rebuild to?   This is desirable as it means for the time being you can keep the physical problem drive with its contents intact so you have more recovery options if a rebuild is not completely successful.

I thought from you statement that it had not yet completed.   As was mentioned then an automatic parity check after a rebooot suggest that you did not have a clean shutdown of the array.    The plugin would have informed you if it thought that an unclean shutdown had been detected and that was triggering an automatic check.
 
You might want to read this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

The Share Minimum Free Space value is applied when selecting array drives, not when deciding if the cache pool should be used instead of going straight to the array.   Looking at the diagnostics what you have NOT set is the Minimum Free Space value for the cache pool (it is currently set to,0).   You get to this setting by clicking on the pool on the `main tab.

No.  
 
Unraid is specifically designed to load into RAM from the USB stick on every boot and subsequently run from RAM and use the USB stick for its licence and storing settings.

This is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

Run without the -n option (and if it asks for it add the -L option).  After that you should be able to restart the array in normal mode and I would expect all the data to be intact.

You might want to check that the SMB security setting under Settings->Unassigned Devices is not now set to No when you probably want the (new) Public option.

There is nothing relating to parity on the data drives so removing the parity drive will have no effect on them.
 
Much more likely the difference is due to the version of Unraid used to format the drives.   Newer Unraid releases use a later XFS version which has a larger overhead when formatting a drive.

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.