After upgrading to version 7.3.0, the Docker service has been crashing intermittently. I have to manually restart the service each time, after which everything works normally until the issue occurs again the following day.

There are no relevant errors in the system logs. However, when I check the Docker tab, it shows that the Docker service is not started.

Please let me know what addional information Ican provide to help. I also upgraded to 7.3.1 same issue and never had this issue before on 7.2.6 or lower.

Please post the diagnostics next time it happens.

Woke up this morning to this:

I already restored a older docker image to make sure it is not the image causing the issue.tower-diagnostics-20260530-0713 - after docker restart.zip

tower-diagnostics-20260530-0701 - Before Docker restart.zip

I don't see any issues logged. Do you still have the problem if you disable CA auto update?

I can try but when I run it by adjusting the time, I had no crashestower-diagnostics-20260530-0750 - after CA auto update.zip

Please let me know next steps as CA auto update did not crash docker service

Edited May 30May 30 by anicol

Post new diags after it happens again to see if this time there's something logged.

tower-diagnostics-20260604-0808.zip

Crash this morning around 7:30-8am est

Crash is still the Docker service only, correct?

I still don't see anything logged, and the last line on the syslog is from 06:29 am.

You could try recreating the Docker image to see if it helps.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file

Then:

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

Also see below if you have any custom docker networks:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

Will do. Question, as you suggested to rebuild the docker image would it be better just going to directory or stay with the image?

I recommend an image; in my experience, folders can sometimes cause weird issues.

I rebuilt the docker img this morning and at around 2:45pm est the service crashed again

tower-diagnostics-20260605-1446.zip

Not sure is this helps

This is now confirmed not a corruption issue. The docker.img rebuild would have wiped all container layers clean — and it crashed again anyway with the same panic. That means the bug is in the Unraid 7.3 Moby/Docker build itself, not your data.

Notice the goroutine IDs reset (592983, 1284596 — same IDs as the very first crash on May 28). These are the same crashes replaying from scratch on a clean image, which proves the corrupt layer theory was wrong.

The crash is triggered by GetContainerLayerSize being called concurrently across all containers on startup, and the NaiveDiffDriver has a race condition or bug in this Moby build when doing parallel diff calculations. It’s not your containers — it’s the code.

What to do right now:

Check if there’s a 7.3.2 or later available:

cat /etc/unraid-version

Then check the Unraid release notes/forum for any 7.3.x hotfix addressing Docker daemon crashes. This is almost certainly a known issue by now given how reproducible it is.

In the meantime, the practical workaround is to disable container size reporting in the Unraid Docker UI, which stops the GetContainerLayerSize calls from being triggered:

Settings → Docker → “Show container size” → set to No/Disabled

That should stop the crash trigger without needing to wait for a fix. Try that first.

38 minutes ago, anicol said:

Not sure is this helps

This is now confirmed not a corruption issue. The docker.img rebuild would have wiped all container layers clean — and it crashed again anyway with the same panic. That means the bug is in the Unraid 7.3 Moby/Docker build itself, not your data.

Notice the goroutine IDs reset (592983, 1284596 — same IDs as the very first crash on May 28). These are the same crashes replaying from scratch on a clean image, which proves the corrupt layer theory was wrong.

The crash is triggered by GetContainerLayerSize being called concurrently across all containers on startup, and the NaiveDiffDriver has a race condition or bug in this Moby build when doing parallel diff calculations. It’s not your containers — it’s the code.

What to do right now:

Check if there’s a 7.3.2 or later available:

cat /etc/unraid-version

Then check the Unraid release notes/forum for any 7.3.x hotfix addressing Docker daemon crashes. This is almost certainly a known issue by now given how reproducible it is.

In the meantime, the practical workaround is to disable container size reporting in the Unraid Docker UI, which stops the GetContainerLayerSize calls from being triggered:

Settings → Docker → “Show container size” → set to No/Disabled

That should stop the crash trigger without needing to wait for a fix. Try that first.

BTRFS info (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0

I would consider running an extended memtest from the boot menu over night. something is causing metadata corruption to appear inside the docker.img which unfortunately is caused by bad ram most of the time.

Also you have an SSD in your array, that is not recommended due to no trim support, you will likely prematurely kill the SSD. Another recommendation is to move that to a dedicated pool by itself.

This all started after upgrading to 7.3 and 7.3.1 bit hardware changes. Also my SSD is not part of the array. To prove it is not hardware, would it be recommended to downgrade back to 7.2.6 and run it for a week or so?

Yeah That's on me, I saw it in the diags but didnt note that it was unassigned. Its ultimately your call but a memtest overnight would rule out faulty ram a lot quicker than running it for a week and potentially suffering silent corruption elsewhere in other data.

Could be an issue with that specific container and the newer Docker engines, so it may be worth to retest after a downgrade.

Which container? I am not seeing anything wrong with ram so just downgraded. Also google shows others having issues

You would need to test, for example, just having half of the container running; if it doesn't crash, try the other half, then keep drilling down.

Downgrade did not fix the issue. I will take out one of the ram sticks and see if it occurs. If it crashes again I will switch the remaining ram stick and test again. Here are the logs if you can see anything additional now being on 7.2.6.

tower-diagnostics-20260609-0757.zip

Btrfs detected a checksum error on the Docker image:

Jun 9 07:56:52 Tower kernel: BTRFS warning (device loop2): csum failed root 505 ino 15795 off 110592 csum 0x2c24046c expected csum 0xd1100c87 mirror 1

Jun 9 07:56:52 Tower kernel: BTRFS error (device loop2): bdev /dev/loop2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0

This could be bad RAM.

I will remove RAM tonight when I am home. It just crashed again so I moving the docker.img to another drive to rule out drive.

Well JorgeB you are right. Weird how test past on ram but when I removed all the sticks and tried one by one. it failed to boot with one of the sticks. Been stable for 22 hours when I removed it from the system. I will give it a couple days and upgrade back to 7.3.1.

Thank you for the awesome support and assistance.

19 hours ago, anicol said:

Weird how test past on ram

When running a memtest, it often needs to run many cycles (recommended to run minimum 24 hours) to rule out if it's bad. Obviously if it doesnt boot with a specific stick I would say that also is a definitive answer.

Thank you again for all the help!!!!! I have been sable for days now and on 7.3.1 for over a day.