trurl

Warnings and alerts are immediate. Unraid monitors certain SMART attributes for each disk, the default attributes are in Disk Settings, and these defaults can be overridden for each disk.

That is the same syslog that is in your diagnostics. You need to post this one

Didn't fix mine. Do you also have something entered as the label in Docker Compose?

Are these orphans? You can delete orphans from the Advanced View of Docker page.

From your earlier thread: Nothing can move or delete open files. As long as the Docker service is enabled, you can't delete or move that user share. I suggest starting over with a docker.img of about 50G. You can easily reinstall all your containers from Previous Apps. https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Why are you using a docker folder? Looks like you probably had 130G docker.img previously, which is much larger than should be needed, so I am guessing you switched to docker folder because you kept filling docker.img. The usual cause of filling docker.img is an application writing to a path that isn't mapped. Also, your appdata and Docker (where you have your docker folder) shares have files on the array. What dockers are you running?

And you will need to reboot to clear the logs

Setup Notifications to alert you immediately by email or other agent as soon as a problem is detected.

Linux doesn't know that user shares are just a different view of the disks. If you mix user shares and disks when moving/copying, you can lose data by specifying a source path and destination path that are actually the same files. This results in creating a new empty file at the destination, then there is nothing at the source to copy.

You don't need krusader, and if krusader is configured to allow you to access individual disks, you must be sure you don't mix disks and user shares when moving/copying. Built-in File Manager won't let you make that mistake.

It's a good idea to keep some space free on each drive in case filesystem repair needs some space to work in. Disk5 also doesn't have much free space.

Attach Diagnostics ZIP to your NEXT post in this thread.

That should be fine. Split level just tries to keep files together on the same disk if they belong together (are in the same folder). Highwater allocation often has the same result, where files that are written at the same time likely will end up on the same disk. The only penalty for files that belong together ending up on different disks is a delay when spinning up another disk. And since split level takes precedence over allocatiion and Minimum free, there can be some downside to making it keep files on the same disk, where it might try to put files on the same disk even if they won't fit.

Set number of array slots to 4 and assign parity, disk1, disk2, skipping parity2.

rsync won't give a clone. You may have to New Config to get the new drive accepted with its contents.

which you needed to do anyway so you can restart it in Maintenance mode to check filesystem on disk18

If you don't actually have a pool named cache, /mnt/cache is a path in rootfs, the RAM reserved for the OS. Anything stored there won't persist. Check the host volume paths for the containers.

You also have to set the Remote syslog server field. If logging to the same server, you can put localhost.

Stop the array and increase the number of drives for the current pool.

You didn't

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/cache-pools/#removing-disks-from-a-pool

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Can you boot anything else such as memtest86 from another flash?

What do you get from command line with this? ls -lah /var/logand this? du -h -d 1 /var/log

I didn't see any evidence of this in previous diagnostics, but you might check rootfs usage occasionally in case a docker or something is filling up the OS space. This command line: df -h /