itimpi

Delete its .plg file from the config/plugins folder on the flash drive (or rename it to have a different file extension) and then reboot.

The process for replacing parity drives is the same as that for replacing data drives.  In theory you can do both at once although you may prefer to do them one at a time in case a data drive fails during the parity build.
 
Replacing a data drive needs to be done as a separate step so cannot be combined with replacing a parity drive.

Yes

If you install the Parity Check Tuning plugin even if you use none of its capabilities for pausing/resuming array operations the entries in the Parity History will be enhanced to give additional information including this type of information.

Check in the config/shares folder on the flash drive that there is a .cfg file for the share with the same spelling AND capitalization as the actual share folders on your drives.   Looks like there may be a mismatch on capitalization.
M---a shareUseCache="yes" # Share does not exist m---a shareUseCache="no" # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8  
After checking (and correcting) the case issue, check the share settings are now as you want them (primary cache, secondary array, mover direction cache->array)  and make a dummy change (e.g. change the comment) and hit Apply to write a new configuration file.

I think that there is a good case for the "Every Day" and "Every Week" options to be removed from the GUI as both of these are far more frequently than is required.

No, SATA connected disks should never disconnect unless caused by an external factor such as cabling or power glitches.

According to that SMART report you have only successfully run the Short SMART test.   If you want to really test the health of the drive you need to run the Extended SMART test and if that fails the drive should be replaced.

In principle it is just plug in and go for basic NAS functionality as long as there is no hardware RAID cards involved.
 
If you have VMs with hardware pass through then the IDs may change and need redoing.

If it readable in Linux then no need to think about imaging.    You just need the config folder from the flash drive as that contains all your settings and licence.  
 
Having said that I am surprised it would be readable in Linux and not Windows as it is in FAT32 format which is a standard Windows file system

This is expected as at this point the disk contains no file system (it is all zeroes having just completed a Clear) as mentioned here in the online documentation.   At this point you are expected to format the drive to the desired file system from within Unraid, but just make sure that is the only drive that Unraid shows in the list of unmountable drives to be formatted.

According to the diagnostics the share anonymised as 
P--------a shareUseCache="yes" # Share exists on cache, disk1, disk2 does not seem to have ‘cache’ set as its primary storage which would explain why files are not being moved.
 
i suggest you go into the settings for that share, check they are correct (and if necessary make a dummy change to get Apply enabled) and then hit Apply to get the .cfg file for that share regenerated.
 
Hopefully that will fix the mover issue, but if not post new diagnostics so we can check the settings now look correct.

Both disk are throwing errors that look like they might be cabling related (power or SATA) so definitely worth checking they are properly seated.

The Settings->New Config tool allows you to change the drive configuration keeping the data intact on the drives that you are keeping.

Not sure what messages you are referring to?
 
Your diagnostics show that you have filesystem level corruption on disk 4 so you should run a check filesystem on that drive.   It might also be a good idea to run memtest as RAM issues can cause corruption.

I would think the amd64 folder - and you are probably after a SATA driver.  You may also want a network driver.

That is the overhead of creating the empty file system structures ready to receive files.

Entries in lost+found is where the repair process could not find the directory entry for a file/folder it found.
 
You have not indicated the current path on disk2 and the path you want to end up with, but you should be able to do something like
mv /mnt/disk2/lost+found/foldername /mnt/disk2/NextCloud adjusting path names as appropriate and assuming that NextCloud is the name of the share you want to end up with.
 
If you do that then the timestamp of the /mnt/disk2/NextCloud folder will probably not be maintained, but I think all the containing files/folders will be.  Just for interest why are you that worried about the timestamps anyway - surely getting the files back in the correct location is the key requirement and the timestamps is just a nicety?

Reboot the system and you will be back to normal.

If you have the GPU virtualised then the VM output will show in a browser Window.

This could mean the drives in question are subject to the “3.3v problem” (Google for more details).

According to the last diagnostics you posted Unraid is seeing disk1 and the SMART information for it looks fine.  If so then you can check that the data in the emulated disk1 looks correct, and if so clear the disabled status by Rebuilding the disk onto itself.   If you have a spare disk then you can rebuild onto that drive instead keeping the original disk1 intact in case the rebuild fails for some reason as that gives additional recovery options.

I would try downloading the zip file for the release and extracting all the bz* type files overwriting the ones on the flash.    This seems to quite often solve any issues reading them from the flash drive.

Looking at the syslog in your diagnostics python is being installed by the cache-mover plugin.

This is not supported by Unraid.   You need separate shares to achieve this