itimpi

You need to format the 14TB drive to create an empty file system on it and make it ready for use. This is always required when adding a drive to a new slot in the array. Since we do not know what state the parity is in from your previous attempt to add disk4 I would strongly recommend now running a correcting parity check to make sure that parity is in sync with your array drives. You can always remove Historical Devices from the UD section. They are kept there so that any settings you applied to the drive last time it was used will still be set. Removing them means that if is then attached again you get the default UD settings for the drive.

You should be able to get the system's diagnostics zip file created via ssh. Posting that here might give us a chance to see what is going on.

Unraid only supports booting off the flash drive (and loading the OS into RAM. Not sure why you have to ‘interrupt’ the boot sequence - the flash drive should be set as the default boot drive in the BIOS to avoid this. Have you read this section of 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. It covers transferring the licence to a new flash drive.

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.