itimpi

I would definitely be worried about that on a new drive - particularily if the number is still increasing.

That will not allow you to change the scheduling as Unraid is still responsible for starting the checks. However the standard scheduling can handle quarterly.

What you need is the parity swap procedure which is designed for exactly this scenario. It allows you to upgrade a parity drive to a larger one and then use the old parity drive to replace the failed data drive.

Are there any periods within the time spanned by the syslog in the diagnostics you posted that you know this occurred to help narrow the search criteria.

This. You cannot do an ‘in place’ encryption.

The Linux ‘file’ command can be used to work out their likely content type which can be useful in working out what app can be used to open them for examination. There is no automated way to work out the original name. The reason a file gets put there in the first place (with the numeric name) is that the system was unable to work out what the name should be. It takes manual inspection of the contents.

No idea if it is a RAM issue or not! Just pointing out that it is very easy to get the docker.img file back into a known clean state. If you continue to get corruption then either the device holding it has a problem or you quite likely do have a RAM issue.

It is always easy to recreate the docker.img file if it gets corrupted and restore containers with settings intact via Apps->Previous Apps so, as long as the underlying XFS file system look OK, I would probably recommend doing that.

If you restart in normal mode then the drive should mount OK. Look for a lost+found folder where the repair process will put any files/folders it found for which it could not find the directory entry giving the correct name.

As long as you have the original drives intact after the rebuild then you can always check the data integrity at a later date.

You do not mention if the arrays have parity protection? If they do then you would have to use the New Config tool to add the drive and then rebuild parity. As far as I know there should be no ZFS compatibility issues. I believe you could also add it as a single-drive pool directly. I have not actually tried this myself so if you go that route would like confirmation I am right.

@mattiscg just to check the obvious, have you actually set any shares to be visible on the network (by default none of them are)? You did not post your system’s diagnostics zip file so we cannot look there to see.

Had a quick look there and nothing shows up to indicate the cause of your issue. The last thing logged appears to be at just after 12:30 at night - do you by any chance have anything scheduled to start then?

The fact that drives are doing a parity sync should be irrelevant. You do not mention what type of SMART error it is and since you did not post your system's diagnostics (which includes amongst other things SMART reports for your drives) we cannot look for ourselves to see if there appears to be genuine problem.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. 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 leads up to a crash. 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.