Just now got my server back online after a few months of downtime due to a PSU failure. Everything was working great last night after getting it back online. In that time, I'd added the Apache WebDAV Docker service to use with my new phone I'd gotten since it'd been offline, had it pointed to read only on all of /user. Was working well when I went to sleep. Aside from that, some new torrents and updating old Docker images, nothing new on that front. Noticed my qBittorrent was behaving badly this evening, so tried to restart it, which resulted in a generic server error message and the container being unable to restart. Went ahead and downloaded 7.2.3 and restarted the system. Now my Docker service reads failed to start.

tower-diagnostics-20260128-2045.zip

Looks like docker.img was 50G, more than should really be needed if things were configured correctly, but it wasn't enough.

Then you changed it to 80G and it still wasn't enough.

The usual cause of filling docker.img is an application writing to a path that isn't mapped.

Delete and recreate as 50G. Don't reinstall Apache since that may be what pushed it over the edge.

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

Also these:

Jan 28 20:45:30 Tower root: Fix Common Problems Version 2025.08.07
Jan 28 20:45:30 Tower root: Fix Common Problems: Warning: Share appdata set to cache-only, but files / folders exist on the array
Jan 28 20:45:30 Tower root: Fix Common Problems: Warning: Share system set to cache-only, but files / folders exist on the array
Jan 28 20:45:30 Tower root: Fix Common Problems: Warning: Email selected as a notification destination, but not properly configured
Jan 28 20:45:31 Tower webgui: File_put_contents_atomic failed to write / rename /mnt/disk1/146779777.tmp
Jan 28 20:45:31 Tower root: Fix Common Problems: Error: Unable to write to disk1
Jan 28 20:45:34 Tower root: Fix Common Problems: Other Warning: Background notifications not enabled
Jan 28 20:45:34 Tower root: Fix Common Problems: Warning: Share appdata set to use pool apps, but files / folders exist on the cache pool

Actually, before you try to fix docker, after you delete docker.img, leave docker disabled. You need to fix some of those other things before you try to do docker again.

Most importantly, disk1 is completely full.

1 minute ago, trurl said:

Most importantly, disk1 is completely full.

And that is where your docker.img is (but shouldn't be).

I went ahead and recreated it, moved it to the Apps drive pool, thought I'd done that when I set it up but I guess not. Got all the necessities back up and running and I think got everything important configured more correctly, here's what I changed. If I have anything else that's a ticking time bomb I'd like to change it too, but thank you for the help on ID'ing the problem.

tower-diagnostics-20260128-2120.zip

appdata                           shareUseCache="only"    # Share exists on apps, disk1, disk2, cache
domains                           shareUseCache="only"    # Share exists on disk1
isos                              shareUseCache="only"    # Share exists on disk1
system                            shareUseCache="only"    # Share exists on disk1, apps

Docker/VM related shares should have all files on pool with nothing on the array, so dockers/VMs will perform better, and so array disks can spin down since these files are always open. You have appdata and domains configured to be only on the apps pool, but that won't get the existing files moved. Same for isos and domains on the nvme pool.

Probably your old docker.img is still in the system share on disk1 so you can delete it now.

Probably libvirt.img is also on disk1. Nothing can move open files so you have to disable VM Manager to move that to apps and the domains and isos shares to nvme.

And appdata of course. You will have to disable docker to move that one to apps. As you can see, it has files all over the place.

You really should fix these also.

Jan 28 20:45:30 Tower root: Fix Common Problems: Warning: Email selected as a notification destination, but not properly configured
Jan 28 20:45:34 Tower root: Fix Common Problems: Other Warning: Background notifications not enabled

1 minute ago, trurl said:

Probably your old docker.img is still in the system share on disk1 so you can delete it now.

Probably libvirt.img is also on disk1. Nothing can move open files so you have to disable VM Manager to move that to apps

Actually, you have system share configured to be on nvme, not apps. And you already moved docker.img to apps instead of to nvme where the other system files belong.

I went ahead and moved libvirt to apps like you suggested, was indeed still stuck on disk1. Appdata had a few empty files on disk1, weirdly UrBackup had a bunch of tiny config files on disk2, but I got everything moved over. Few other random 0B things on disk1, can't find them in file manager but they're all registered as 0B still looking at the share utilization. When I turn off my torrents that could possibly be querying stuff on it that seems to stop all reads and writes off disk1, so hopefully that fixes it. Disabled the email service, forgot I had that enabled since I use Telegram, don't need it, and turned on the CA emergency notifications. Thank you!

2 minutes ago, Qcoo said:

I went ahead and moved libvirt to apps like you suggested

But that isn't where you have system share configured to be

19 minutes ago, trurl said:

you have system share configured to be on nvme, not apps

Ah you're right, I'll get it moved over to NVMe too. Actually haven't ran any VMs on my server yet so not really used it enough to notice. Leveling out my usage in some bigger folders to give disk1 some breathing room right now, but I'll do that next.

docker.img is in system share too, but you also moved it to apps

36 minutes ago, trurl said:

And you already moved docker.img to apps instead of to nvme where the other system files belong.