itimpi

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.

No - you DO get all Unraid features (including VMs and Docker) and keep your lifetime update status. All releases of Unraid are functionally equal, and the web site should make this clearer.

You have this in your syslog: Apr 23 09:32:36 Tower root: Fix Common Problems: Error: Macvlan and Bridging found so it appears you are using macvlan for docker networking. If using macvlan then for stability you need to disable bridging on eth0. The alternative is to use ipvlan for docker networking.

You could try installing the nVidia Drivers plugin. Whether it supports that card or not I have no idea.

Did you get an automated acknowledgement of your request?

Do you have any drives showing as unmountable as if you have any files on those drives will not currently be available? 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.

That is what most people seem to use for pools although it is not mandated.