trurl

You should add attributes 1 and 200 for monitoring on all your WD drives. When you do, you will see several drives with SMART ( 👎 ) warnings on the Dashboard page. And setup Notifications to alert you by email or other agent as soon as a problem is detected.

Looks like you must have already done New Config

contact support

Assuming this is a new flash drive with a new key file, then copy config folder from your flash backup except for the old key file.

Dynamix File Manager is a plugin and will work with Docker disabled. It will be built-in with v6.13

I don't see any reboots in that syslog

These latest diagnostics shows appdata, domains, and system shares with files on the array. Ideally, these would all be on cache or other fast pool, so Dockers/VMs will perform better, and so array disks can spin down since these files are always open.

Here is a post I made some time ago about 2 "surprises" to watch out for

I only meant that your syslog showed the files that had been moved. Examine it for yourself to see what I mean.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/

speed isn't important for the boot drive. Does it have a unique GUID?

Another possible cause of corruption is bad RAM.

Unraid will not automatically reboot. Some BIOS can be set to boot when power is restored, otherwise rebooting on its own suggests a hardware problem.

Post new diagnostics

Often the cause of docker image corruption is overfilling it. And filling docker.img is often caused by an application writing to a path that isn't mapped. I have been using default 20G docker.img for years with no problem, but I have never ran more than 16 containers.

You should go to Scheduler settings and disable Mover logging.

The quoted post seems to be gone, and it was made by a user that has only made incorrect posts since joining yesterday. ChatGPT?

Also, Mover ignores any share where there is no Mover Action specified, which is what you have for all of those. appdata shareUseCache="only" # Share exists on cache, disk4 domains shareUseCache="only" # Share exists on disk4 isos shareUseCache="only" # Share exists on disk4 P-------e shareUseCache="no" # Share exists on disk3 P---------V shareUseCache="no" # Share exists on disk4 system shareUseCache="only" # Share exists on disk4 They need to be Primary:cache; Secondary:array; Mover Action:array->cache

That seems to correspond with when parity check was paused. Mar 26 06:30:01 Tower kernel: mdcmd (39): nocheck pause Mar 26 06:30:01 Tower kernel: Mar 26 06:30:01 Tower kernel: md: recovery thread: exit status: -4 Later on syslog says Mar 27 00:30:01 Tower kernel: md: recovery thread: check P Q ... ... Mar 27 03:57:12 Tower kernel: md: sync done. time=12431sec Mar 27 03:57:12 Tower kernel: md: recovery thread: exit status: 0

Attach Diagnostics to your NEXT post in this thread.

Nothing can move open files. Disable Docker and VM Manager in Settings. Attach Diagnostics to your NEXT post in this thread

Start the array with disk3 unassigned and post new diagnostics. Do you have a spare to rebuild disk3 to?

Parity knows nothing about filesystems, it is all just bits. Rebuild will result in the same bits on the disk, so can't fix corruption Attach Diagnostics to your NEXT post in this thread.

Then libvirt.img is an open file in the system share.