itimpi

You just ran a check - not a repair. To do any repair you need to run without the -n option. If it asks for it you should add the -L option. After that the disk should mount when you restart the array in normal mode.

If you add a parity drove to an existing Unraid array then the sync is automatic when the array is next started. If this did not happen then that implies you did something other than the normal process for adding a parity drive.

Another option would be to always boot into Unraid, and then run Linux as a VM under Unraid if you want both Unraid and Linux running simultaneously.

If the sever is simply rebooting rather than shutting itself down then this almost invariably indicates a hardware issue with the commonest being power or thermal type issues. If you get either of these then nothing will show up in the logs.

Continual resets on a drive showing up in the syslog are typical symptoms of power/connection problems. The simplest check is to run the Extended SMART test on the drive. That test is completely internal to the drive so If that passes then then the drive is normally OK. The only other likely cause would be insufficient power reaching the drive.

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.