itimpi

The 2 step procedure is the way to go.  
 
At each stage make sure you keep the disk just removed with its contents intact until that stage has successfully completed as that gives you a fallback option if anything happens to go wrong.

The syslog suggests you are getting a crash in the driver that handles your NIC.   It might be worth trying the 6.10-rc8 release to see if that has an updated driver/kernel that works OK on your hardware,

You have the CA Backup plugin scheduled to start at 6:00 am every day and that will be what is stopping the containers until the backup is finished.

It depends on the BTRFS profile they are set to use.   The default is raid1 and that means they are protected, but the usable space is only that of the smaller device.

I think you have to copy/paste it into a new script entry within the User Scripts plugin.

I think you have two conflicting requirements here?    If you have the GP’u isolated so that it can be passed through to a VM then it is not visible at the Unraid level and needs to be controlled from within the VM.

After initial boot Unraid runs from RAM so the /etc location is only in RAM and (as you found) not persistent.  If you want to make such a change persistent then you need to apply it every boot.  This is typically done either by adding appropriate entries in the /config/go file on the flash drive or by using the User Scripts plugin.
 

The easiest thing would be to plug the drives into Unraid as Unassigned Devices and use the UD plugin to partition and format them correctly for Unraid (as XFS or BTRFS) drives.   You can then use them on other systems to add files and when you add them to Unraid (as long is there is no current parity drive) then Unraid will accept them and leave their data intact.

Handling of unmountable disks is covered here in the online documentation that can be accessed via the Manual link at the bottom of the GUI. 

If the folder really is empty then you can safely delete it. Nod sure why it was created in the first place if it really is empty.
 
It should also get removed if you:
Disable the Docker service (under Settings->Docker) to ensure it is not holding anything open at that location Run mover manually from the Main tab to move any files that might be there to the cache. Re-enable the Docker service.

This will not work as you cannot expose the raw disk over the network.

You can use Tools->New Config to reset the array and assign the surviving  array drives as you want them.  When you start the array then these assignments are committed and parity (if you have assigned one) is rebuilt from the remaining drives.   Unraid will recognise the drives that have previously been used by Unraid and will leave their data intact.
 
Since each drive in an Unraid array is a free-standing file system they can also be read individually when not part of the array.   Easiest is some sort of Linux system as it will have built in support for the file systems used by Unraid.

This disk looks a bit sick going by the SMART information:
Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: ATTRIBUTE INITIAL NOW STATUS Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Reallocated_Sector_Ct 0 24 Up 24 Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Power_On_Hours 22 67 Up 45 Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Reported_Uncorrect 0 9 Up 9 Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Airflow_Temperature_Cel 28 30 Up 2 Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Current_Pending_Sector 0 8 Up 8 Apr 15 16:02:12 preclear_disk_ZL24A79Y_23305: S.M.A.R.T.: Offline_Uncorrectable 0 8 Up 8
As this is a new disk then it sounds as if it was damaged in transit and you should RMA it.  For instance on a new drive you would expect Reallocated Sectors and Pending Sectors to be 0.

If you are running the script via the User Scripts plugin then including the line
#noParity=true in the script will achieve this
 

That screenshot shows 2 drives missing or failed but only single parity so Unraid cannot do the parity swap.

Those ‘critical medium error’ messages almost certainly mean that the SSD is faulty.

Isn’t that already there?  
 
blank = not exported
italics = exported (hidden)
normal case = exported 

Are you running Unraid 6.9.2 or 6.10.0-rc4?    If the former I would suggest installing the Config File Editor plugin to edit the files, while if the latter the File Manager plugin will allow this.

Ok - the drive will not be mountable until you have run format on it.

The URL will not work from the GUI if you have no internet access from your server.
 
have you tried simply using the URL from a browser to download the key file and then copying the key file into the ‘config’ folder on the flash drive?

Did not spot something obviously wrong in the SMART report, although you might want to consider running an extended SMART test on it.
 
if you think the drive is OK then the process for getting it back into the array is documented here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.
 

Changing the drives to different slots invalidates parity2, but parity1 is unaffected.
 
You could do what you want by:
use the New Config tool using the option to keep current assignments go to the Main tab and unassigned parity2 and put the data drives into the slots you want check the option to say parity is valid start the array to commit the revised assignments.   Since you ticked the parity is valid checkbox the drives should all mount fine and parity1 is NOT rebuilt stop the array assign parity2  start the array to start the build of the parity2 contents.

According to the syslog the docker image is corrupt:
Mar 20 08:40:44 MAHomeLab kernel: BTRFS critical (device loop3): corrupt leaf: root=1 block=47251456 slot=16, invalid root generation, have 882824 expect (0, 882323] Mar 20 08:40:44 MAHomeLab kernel: BTRFS error (device loop3): block=47251456 read time tree block corruption detected Mar 20 08:40:44 MAHomeLab kernel: BTRFS critical (device loop3): corrupt leaf: root=1 block=47251456 slot=16, invalid root generation, have 882824 expect (0, 882323] Mar 20 08:40:44 MAHomeLab kernel: BTRFS error (device loop3): block=47251456 read time tree block corruption detected Mar 20 08:40:44 MAHomeLab kernel: BTRFS: error (device loop3) in btrfs_recover_log_trees:6401: errno=-5 IO failure (Couldn't read tree log root.) Mar 20 08:40:44 MAHomeLab kernel: BTRFS: error (device loop3) in btrfs_replay_log:2423: errno=-5 IO failure (Failed to recover log tree) Mar 20 08:40:45 MAHomeLab kernel: BTRFS error (device loop3): open_ctree failed Mar 20 08:40:45 MAHomeLab root: mount: /var/lib/docker: can't read superblock on /dev/loop3.  
There are also errors reading from the SSD:
Mar 20 08:40:52 MAHomeLab kernel: BTRFS error (device nvme0n1p1): parent transid verify failed on 761778012160 wanted 5863377 found 5857159 Mar 20 08:40:52 MAHomeLab kernel: repair_io_failure: 2 callbacks suppressed Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778012160 (dev /dev/nvme1n1p1 sector 2564352) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778016256 (dev /dev/nvme1n1p1 sector 2564360) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778020352 (dev /dev/nvme1n1p1 sector 2564368) Mar 20 08:40:52 MAHomeLab kernel: BTRFS info (device nvme0n1p1): read error corrected: ino 0 off 761778024448 (dev /dev/nvme1n1p1 sector 2564376)  

Reiserfs cannot handle drives that are larger than 16TB.

Not quite - I do not think a trial will accept the disk assignment from a full licence version so you have to reapply them.  Easy enough to do as long as you know what the assignments should be and you can then tick the parity is valid checkbox to avoid rebuilding parity.  All other settings in the config folder should come across without issue.
 
You did not mention why you could not get the trial working