itimpi

Why bother to back up docker.img.?  
 
If needed it is trivial to retreat the docker.img file and reinstall all your containers with settings intact as described 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. 

Unraid has a custom md driver that works at the block level for array drives below any file system so is file system agnostic.
 
Unraid has no automatic file integrity checks that covers all file systems supported, but if you use a file system such as btrfs or ZFS which does have such checks then you get them for the drives using those file system types.
 

You could try this process as it often fixes issues reading from the flash drive.
 
In terms of settings they are all stored on the flash drive in the 'config' folder.   You should see if you can make a copy of that while on a PC/Mac trying the process mentioned above.

You need to run the SMART Extended test to properly test the drive - the Short test is often insufficient in finding errors.

Your diagnostics show macvlan related crashes and these are known to eventually crash the server with the 6.12.x related releases.    You should either switch docker to using ipvlan via settings->Docker (Advanced view) and reboot, or if you want to continue using macvlan make sure you have followed the requirements for this in the release notes.
 

This will be from the continual resets on disk1 that I mentioned.  You should abandon the parity build; fix that problem; then start the parity build again.

The release notes say that you need to disable bridging if you do not want Macvlan crashes to eventually crash the server when using Macvlan.   Why if have no idea.

You approach would work, but at the end you would have parity2 but no parity1 drive.  Some people prefer to not be in that situation..  
 
Another option is to replace the 8TB parity drive with the 16TB one and let Unraid build parity on that.    Keep the old parity drive  intact until that finishes just in case something goes wrong.   When you have rebuilt parity on the 16TB drive follow the standard process for adding a new drive to the array to add the old 8TB drive as a data drive.

That looks like it might be macvlan related which is known to cause a server to eventually crash on the 6.12.x releases.    You should either switch your docker containers to to using ipvlan networking, or follow the instructions in the 6.12.5 release notes to continue using macvlan.

It is simply saying that disk1 is over the utilisation warning threshold currently set for that drive and is nothing to do with the shares.

You need to run without -n and add -L (Unraid has already failed to mount the drive) to get the repair done.   Afterwards you need to start the array in normal mode and see if you have a lost+found folder which is where the repair process puts anything it cannot figure out.

Your ‘system’ share was on disk2 in the last diagnostics, and that share contains the docker,img file which is probably causing your issue.   You normally want that share to be on a pool if at all possible both to minimise array reads/writes and also maximise  performance of docker containers..

Have you installed the Dynamix File Manager plugin?

Have you installed the Dynamix File Manager plugin?

Not clear what you mean by a mount point?     If you mean the sdX type device names then these are irrelevant as Unraid does not rely on them and anyway they can change between boots.

This is described in the User Shares section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.   The Unraid OS->Manual section covers most aspects of the current Unraid release.

The same page that has the USB Creator tool for download also has the links to download the zip files for the latest Unraid releases that can be used with the manual install method.

Do you have the Cache Dirs plugin installed?   That will issue regular find commands to try and keep directory information cached in RAM.

The trailing ~ needs to be removed if you want to be able to boot in UEFI mode.

Did you change the volume mapping to point to /mnt or just try going to /mnt inside the container without changing the mapping? 

The 015 would explain it as the leading 0 means it is treated as octal number and 015 in octal is 13 in decimal
 

Removing the Mover Tuning plugin seems to fix this.   Quite why that plugin is causing problems I have no idea.

It is not the subnet mask that matters, but the first 3 bytes.   They need to be the same on the router that Unraid is connected to, and on the Unraid server.

No idea about that script, but if you install the Parity Check Tuning plugin it gives you the ‘parity.check’ CLI command that makes it easy to do what you seem to be looking for.

No.   Unraid will be emulating the drive and it will appear to be present throughout the rebuild and you will be able to read/write it as though the drive had not failed.   Performance will be degraded during the rebuild and you are not protected until the rebuild completes.
 
Correct (unless you have 2 parity drives).
 
Yes.
 

This normally ‘just works’.  Unraid does not care how drives are connected as it recognises them by serial number.   I think this is one area where people are pleasantly surprised with how psinless it can be.
 
Things that can go wrong (but are normally easily worked around) is if one motherboard had a RAID disk controller and the other an HBA  so the disks were presented with different serial numbers of different sizes.  
 
VMs with passed through hardware might need to be handled carefully as the IDs of the passed through hardware will almost certainly change