itimpi

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

Looking at those diagnostics it looks like the disk you were talking about is disk11?
 
If so then I notice that disk11 has 320 reallocated sectors so the errors may have been related to that happening.   While reallocated sectors are not necessarily a problem it would be a problem if that value keeps increasing.

If a drive cannot complete the Extended SMART test it should always be replaced.   If it is still under warranty then failing that test is normally enough to get a RMA.

The last thing before the crash appears to be a macvlan related crash and such crashes seem to eventually crash the whole server.  Either switch docker to using ipvlan or make sure you have macvlan set up as indicated in the 6.12.4 release notes.
 

You need to enable SSH under Settings->Management Access.  At the moment it appears to be set to No.

Total disks in the system at the point the array is started regardless of whether they are being used by Unraid (and excluding the boot flash drive).  Removable drives plugged in after the array is started do not count towards the limit (but would need to be unplugged before the next time the array is started to not count at that point).

You should download the zip file for the release and extract ALL the bz* type file overwriting those on the flash drive 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.  

There were no obvious indications I could see that the drive in question is dying - just that there was file system corruption on the drive.
 
 
Drive can have many alternate names - md5 refers to disk5 in the parity protected array once it has been started.
 
You should run a check filesystem on disk5 to correct the file system errors.  If you do this from the GUI then you do not have to worry what name to use for the drive as the GUI takes care of this for you. 
 
If you simply replace the drive then the replacement will be rebuilt with exactly the same file system errors so you normally want to get this corrected before the rebuild (assuming you even want to go ahead with the replacement once the file system is corrected). 

When you use rsync then trailing slashes on the paths used are important - it looks like you go one of them wrong 🙂
 
You can probably correct most of the issues by using the 'mv' command from a console session and this would be the quickest.    If for any reason there are any issues doing this or you are not comfortable with the command line I suggest you use the Dynamix File Manager plugin to move them.
 
Since you also mention that you were not able to access the folder contents you probably also managed to get the permissions messed up so you should run Tools->New Permissions against disk17.

If you want to move the files to the main array this needs to be set to cache_ssd->array.     Your current setting is what you would use later to move the file back to the cache.

Each docker container can have its own requirements around any folders/files that are part of its working set located in a folder under the appdata share so the only foolproof way to fix it is to remove the relevant folder in appdata for a particular docker container and let it be recreated from scratch.  Any mappings to other shares should be OK.   You can do this for just those docker containers that have problems if you can identify them.
 
You can delete the folder using the Dynamix File Manager plugin with the relevant docker container stopped and then restart the container to get the folder recreated.   If there are any containers where you really do not want to loose the current working set data then you would have to ask for guidance on that particular container in its support thread.

The 'loop' devices are used to support docker and VMs.  In your case loop2 almost certainly refers to your docker.img file which by default is formatted as BTRFS internally.   You should follow the instructions here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI to create a new empty image file and then re-instate and repopulate this file with your previous docker containers with settings intact.