itimpi

You might want to delete (or rename) the config/vfio.cfg file on the flash drive.    There is a good chance that with a new motherboard the device ID's for passed through devices are different.

It is not certain from your description if it is the new drive you have just added or not,  At this point I would suggest running a correcting parity check (which should report the same 2 errors as it corrects them), and then run another non-correcting check which should now report 0 errors.  
 
if you still have errors reported then please post your diagnostics. 

Not using standard features as Unraid only supports top level shares
 
Should be able to do it if you are prepared to five under the covers to do manual configuration but this would be error prone.

Normally closing the window also kills the process.
 
You could look at using ‘screen’ to get around this limitation.   I know screen can be installed via the NerdTools plugin.   You can use Google to get instructions on running ‘screen’.

The file on the flash drive config/shares/Music.cfg is corrupt.  All .cfg files should be human readable and that file is not.  You should delete it and after doing that go into the Music User share settings and check they are what you want as they will have reverted to default settings.
 
I would suggest you also do the following:
Put the flash drive into a PC/Mac and let it check it for consistency. Make a backup of the config folder from the flash drive in case the corruption indicates a potential problem with the flash drive.

The only thing I might do differently is use btrfs for the pools, but this mainly because I am familiar with it and not yet as much with ZFS as it is new to Unraid.

Yes.

What you want is not possible.   However an alternative approach (as long as you are on the 6.12.x release) might be to use the 2 10TB drives in a ZFS pool instead.

These are not normally an issue unless they are increasing at a steady rate.    They indication connection issues between the drive and the host machine and are typically caused by power or SATA cabling issues.   If one is encountered then the host will retry the transfer so the typical impact is just to slow things down unless the retries all fail and as a result a transfer actually fails.  It is worth noting that the CRC count never resets to 0 so once you have some if you can stop them increasing you have fixed the issue.

This is a typical speed for the main array when it has parity protecting and more than one data drive.    Your previous configuration was a special case as with one parity drive and one data drive they act as mirrors.   You may get better speeds if you enable Turbo Write mode, albeit at the cost of having all drives spinning when writing to the array.
 

It does - you can only rebuild to the same file system as the parity rebuild process is unaware of file systems as it work at the raw sector level.
 
If you tried to format it you would have got a popup warning you that this would erase all data, update parity accordingly and that a format is never part of a rebuild. It looks like you continued with the format anyway?
 
If you still have the old 6TB drive untouched you should be able to mount it using Unassigned Devices to get the data back.

You need to first unlock the screen (leftmost icon at top right).

Yes
Why you would think this needed?   Parity has just been used as part of the rebuild process so by definition it is correct.

This only happens if a write to the drive fails.   It is independent of whether a sector is reallocated.
 
passing the extended SMART test is not definitive (although suggestive), whereas failing it is definitely a problem.    Not also that the overall SMART assessment based on the SMART attributes is almost meaningless unless it indicates a failure.

A rebuild does not clear an unmountable state.   Handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Have you set the server to use a fixed IP address either at the server or the router?    The default would be DHCP which means addresses are allocated dynamically.

Are you trying to access a User Share?    If so then make sure the SMB settings for the share do not have the Export option set to No (which is the default).    For security reasons you have to actively use one of the other options to make it visible on the network.
 
if you had provided your Unraid system’s diagnostics zip file we would have been able to see if this was actually the mistake you have made.

The correct process would be:
set the cache as primary storage and secondary storage as the array. set the mover direction as array -> cache disable the docker and vm services under settings manually run the mover to get all the files transferred to cache when that completes remove the secondary storage option from the share re-enable the docker and VM services

FYI:  There is no built-in version of Tailscale - you must be using either the docker or plugin version.

Not sure other than to say it works fine for me 😊.    What security level on the shares (mine are set to Public).

There are various error messages after attempting to mount the docker.img file:
Aug 22 11:11:09 Tower kernel: BTRFS info (device loop2): start tree-log replay Aug 22 11:11:09 Tower kernel: BTRFS error (device loop2): incorrect extent count for 1372585984; counted 8726, expected 8727 Aug 22 11:11:09 Tower kernel: BTRFS: error (device loop2) in btrfs_replay_log:2500: errno=-5 IO failure (Failed to recover log tree) Aug 22 11:11:09 Tower root: mount: /var/lib/docker: can't read superblock on /dev/loop2. Aug 22 11:11:09 Tower root: dmesg(1) may have more information after failed mount system call. Aug 22 11:11:09 Tower kernel: BTRFS error (device loop2: state E): open_ctree failed  
This suggest this file is corrupt and needs to be recreated.
 

The files will still be there!     Unraid will have updated parity so that the emulated disk shows those files.     Whenever you rebuild a disk whatever shows as on the emulated disk before the rebuild starts I s what you end up with (assuming the rebuild was successful). 

You can use the SSD for both purposes, but you cannot set explicit limits on how much space is used for each purpose.
 
You can decide at the share level where each share can have its files located.

You ran with the -n (no modify) option set and that needs to be removed if you want anything to be fixed.    If it asks for -L then add that.

Do not see how as the error message suggests a physical failure to read the superblock.
 
The earlier messages are what we normally see when there is an issue with the SATA or power cabling to the drive.