itimpi

Unfortunately the syslog you posted (and the version automatically included when getting diagnostics) is the RAM version that starts afresh every time the system is booted. so we do not know what happened prior to the reboot. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what preceded the reboot. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. When you say the system got a 'message' to terminate what do you mean? If you mean it started a tidy shutdown is there any chance someone/something (e.g. a cat) could have pressed on the power button to trigger a shutdown? If you simply mean it rebooted itself then this is normally a hardware issue of some kind.

The SMART test failing is never a good sign as it runs completely internally to the drive. The only external factor that springs to mind that could cause this is power issues. If the drive cannot past the Extended (let alone the short) SMART test then we would normally think that it needs replacing.

Do you have macvlan enabled for docker networking? If so you need to make sure bridging is disabled on eth0 to avoid potential system instability.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

You can also try rewriting the bz* type files 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.

You need to run without -n and adding -L

How are they connected? If via USB then it is possible the serial numbers are not being passed through correctly. Some USB enclosures pass them through while others do not.

You seem to have the same drive assigned to disk1 and parity2. Not quite sure how you got yourself into that position. Have you tried setting parity2 to not assigned and then starting the array.

No 14TB drives are showing up in the SMART reports suggesting they are no longer online. The fact that UD has one showing with the same serial but a different ID suggests that drive dropped offline and then reconnected. You probably need to shutdown the server; check power and SATA cabling to both of them; and then reboot to see if either of them is now showing up as expected. Posting new diagnostics at that point might be a good idea.

This is one of those things that seem to be highly variable. Some seem to to get failure in months, while others get many years - 10 years being reported. What does seem to help is getting USB2 drives (I suspect because they typically run cooler than USB3 ones) if you can find them nowadays. Also ones with metal casings can help with heat dissipation. Having said that I have some nano form factor ones that I have been using for years and they are too small to have much cooling. Sounds as if you definitely want to get an automated backup of the flash drive in place going forward. The two standard ways of achieving this are: via the appdata backup plugin which includes an options for the flash drive as part of scheduled backups. Via Unraid connect which supports automated backups to the cloud (on Limetech servers). There is still the manual backup method of clicking on the boot drive on the Main tab and selecting the backup option from there.

This is not an issue if the USB enclosure passes the drive serial numbers through to Unraid as that is the way that Unraid identifies drives, not by the order in which they initialise.

You could simply rename the folder under the appdata share and edit the container settings accordingly. There should be no need to copy the folder in that case. You can use the Dynamix File Manager to do the rename.

Rebuilding a drive will not clear an unmountable status. The procedure for this 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.

The problem with using encryption is that if you end up with file system level corruption then encryption can compromise recovery processes so it then becomes critical that you have a good (and tested) backup strategy in place.

No, it is always based on the number of folders in the files path.