trurl

Attach Diagnostics ZIP to your NEXT post in this thread.

Attach Diagnostics ZIP to your NEXT post in this thread.

Did you change it to docker.img instead of docker folder?

There is an option to delete docker directory though.

Changing to docker folder is not really the fix for growing docker img. Looks like you had given it 90GB and still filled it. The usual cause of filling docker.img is an application writing to a path that isn't mapped. I recommend going back to docker.img, 50G should be plenty, and reinstalling everything from previous apps. Then you can try to troubleshoot your dockers one at a time to see which is filling docker.img https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Not clear how successful you will be with that approach https://forums.unraid.net/forum/118-boot-devices/ Also FYI, the OS doesn't actually run from the flash device, it just contains archives of the OS which are unpacked into RAM at boot, and the OS runs in RAM. You could make an internal boot partition on the cache devices.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/

Attach Diagnostics ZIP to your NEXT post in this thread.

Disk2 doesn't look too bad. Click the FIX button on that one then start the array in normal (not maintenance) mode and post new diagnostics. Then we can consider your options for disk1.

Start your own thread with your Diagnostics.

Your link requires me to login to ChatGPT before I can see what transpired. Not gonna do it. Perhaps you could summarize it yourself.

Sometimes docker folder seems to cause more problems that it solves. And running out of space on docker.img either means you have an application writing to a path that isn't mapped, or your dockers really do require a larger docker.img depending on how many and what applications. Not clear that is the cause of your problems though. The usual advice is to disable Docker and VM Manager in Settings, and also start in SAFE mode to eliminate plugin problems. Run as just a NAS for a while and if it still crashes probably a hardware problem.

Not seeing any connection problems now. But those first diagnostics had all disks mountable but syslog showed some corruption on disk1. Now disks 1,2 both corrupt and unmountable. Do memtest before doing anything else.

You did exactly what the docs say to do if you want to rebuild to the same disk. You unassigned the disk, started the array, stopped the array, reassigned the disk, started the array to begin rebuild. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself But since it is unmountable, the result of the rebuild will be unmountable. Stop the rebuild then post new diagnostics.

Why did you start rebuilding disk1?

That look OK. Why did you decide to use a docker folder instead of docker.img?

then post new diagnostics

Actually syslog indicates connection problems with another disk also. on all disks.

Emulated disk1 is mounted, and SMART report for disk1 looks OK. Syslog indicates connection problem, and also some corruption. Check connections, both ends, SATA and power, including splitters. Careful with connections of other disks. Then check filesystem on disk1.

What do you get from command line with this? cat /etc/cron.d/root

Test each stick one at a time in each slot

Attach Diagnostics ZIP to your NEXT post in this thread.

Copy is faster and safer than move, then you can just reformat after everything is copied. You can't move files from a disk if the disk is readonly since the source files can't be deleted. Just exclude the disk to be formatted from user shares, and the duplicates won't appear in user shares.

Was everything you normally have running at the scheduled shutdown time also running when you did this test?