anicol

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

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.

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.

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

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

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?

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.

I rebuilt the docker img this morning and at around 2:45pm est the service crashed again tower-diagnostics-20260605-1446.zip

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

tower-diagnostics-20260604-0808.zip Crash this morning around 7:30-8am est

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

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

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.

I am having a similar issue. After upgrading to 7.3.0, my docker service keeps crashing. I need to manually restart the service and everything is find again until the next day. App Backup may be causing something, but not sure. The only thing changed on the system is upgrading to 7.3.0 two days ago.

Confirmed as well. Thank you