itimpi

With high-water allocation then the relative size of disks can become relevant as the high-water cutover points are based on the largest drive but your screenshot does not show the sizes so we cannot see if the behaviour is what should be expected.

If you did tis before the rebuild completed then the rebuild would be started again from the beginning.

The end of both logs finishes with errors along the lines of: Apr 22 08:33:48 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 Apr 22 08:33:48 Tower kernel: ata14.00: irq_stat 0x40000001 Apr 22 08:33:48 Tower kernel: ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 7 dma 16640 in Apr 22 08:33:48 Tower kernel: opcode=0x12 12 01 80 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation) Apr 22 08:33:48 Tower kernel: ata14: hard resetting link Normally we would think these were power/sata cabling related but the fact it has occurred at the same point twice suggest it may really be a drive problem if ata14 is the new drive.

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. I strong;y suspect that you have something incorrectly configured. It seems unlikely that mover will report files ‘exists’ when it does not so I suspect that you do not have things set up correctly to get the behaviour you want.

You may find this section of the 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 useful in understanding what is happening and what actions to take.

Have you tried clicking on the orange icon for the drive on the Dashboard to see what error it is? If it is a CRC error then if you. Lick on the Acknowledge option Unraid will only notify you again if it increases. CRC errors are connection related rather than a disk problem and would be triggering retries. They never reset to 0. Occasional CRC errors is not really something to worry about but if you get lots of them you should look into the power and SATA cabling to the drive as the most likely culprits.

You can use the procedure documented 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 Unraid OS->Manual section in particular covers most features of the current Unraid release.

Never heard of 2 HDD drives really having the same serial number before. I feel there must be something that can be done, but no idea what.

That is a clean looking check with no errors reported so I would expect all data to reappear after running the repair.

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.