itimpi

Yes, but it is unreasonable to expect a small company like Limetech to continue to support obsolete versions of their software forever i think the Limetech policy is significantly more generous than I have seen offered on many other products..

It is not quite that simple. You get any security updates that are available for the release you are on at the end of the years paid update period. What you do not get is security updates that are only available in future releases. As an example Limetech says that if when your update support period expires you are on 7.0.x then you get all updates for the 7.0.x releases even though you have not taken out another years of updates support. While Limetech is working on and releasing the next release beyond your current one (i.e. 7.1.x releases) then they will (if possible apply patches to the 7.0.x releases. Once they start releasing the second release beyond yours (i.e. the 7.2.x releases) then the 7.0.x releases will no longer get any more updates. At any point you can decide to take out another year of update support and then you the update to the release current at that time, and after another year the same principle as outlined above applies (which could be you being on a later release than you started the year on).

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.