I've been facing a lot of weird issues lately.

What I tried and didn't result in much of an improvement:

1. Changing the docker folder from a ZFS volume to a btrfs volume

2. Changing RAM (currently running a single stick JEDEC DDR4-3200 from Crucial, passed memtest86+ 3 times, Live Memory Tester plugin 2 loops, etc.)

I originally bumped into this while trying to upgrade some docker containers and getting error messages about not being able to delete images. Suspecting being a bug in the overlay2 + ZFS combination, I switched to a btrfs mirror, but I got the same result after a while.

Symptoms (in the order I notice them)

1. Suddenly some containers crash. Others keep running (luckily Traefik being one of them, whereas the Crowdsec or Redis container living in the same 2. Compose stack die, which led me to being able to see the Crowdsec plugin's error page when trying to access anything I host behind Traefik)

2. docker ps fails due to being unable to access the docker socket. "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"

3. Accessing the Docker tab in the webUI gets me a message "Docker failed to start" and nothing is visible

4. Going to Settings -> Docker and disabling Docker results in it saving the changes forever. If I refresh the page, it says Docker is still running despite being disabled.

5. Trying to enable Docker again works, but all containers have their auto start setting disabled now (?)

6. Trying to start some of the not-started containers (not Compose, just regular unRAID templates via the GUI) gets me "Image can not be deleted, in use by other container(s)"

7. Trying to stop specific containers and/or via docker compose results in errors. Not all containers, just some. See log line below when trying to "docker compose down" my nextcloud stack:

panic: jsonschema: Compile("compose-spec.json"): json-pointer in "file:///boot/config/plugins/compose.manager/projects/nextcloud/compose-spec.json#/definitions/deployment/patternProperties/%5Ex-" not found
goroutine 1 [running]:
github.com/santhosh-tekuri/jsonschema/v6.(*Compiler).MustCompile(0x253c680?, {0x29307c3, 0x11})
        github.com/santhosh-tekuri/jsonschema/[email protected]/compiler.go:172 +0xb9
github.com/compose-spec/compose-go/v2/schema.Validate(0xc000391170)
        github.com/compose-spec/compose-go/[email protected]/schema/schema.go:63 +0x325
github.com/compose-spec/compose-go/v2/loader.loadYamlFile.func1({0x2532080?, 0xc0006c0330?}, {0xc0006e69a8, 0x1, 0x1})
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:481 +0x3ee
github.com/compose-spec/compose-go/v2/loader.loadYamlFile({0x2d37900, 0xc0003a9720}, {{0xc00005c0c0, 0x53}, {0xc00050d200, 0x474, 0x475}, 0x0}, 0xc00068a360, {0xc000632280, ...}, ...)
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:517 +0x53d
github.com/compose-spec/compose-go/v2/loader.loadYamlModel({0x2d37900, 0xc0003a9720}, {{0x0, 0x0}, {0xc000632280, 0x37}, {0xc00021c6c0, 0x2, 0x2}, 0xc000390060}, ...)
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:378 +0x19e
github.com/compose-spec/compose-go/v2/loader.load({0x2d37900, 0xc0003a9720}, {{0x0, 0x0}, {0xc000632280, 0x37}, {0xc00021c6c0, 0x2, 0x2}, 0xc000390060}, ...)
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:538 +0x2f9
github.com/compose-spec/compose-go/v2/loader.loadModelWithContext({0x2d37900, 0xc0003a9720}, 0xc000694800, 0xc00068a360)
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:350 +0x105
github.com/compose-spec/compose-go/v2/loader.LoadWithContext({0x2d37900, 0xc0003a9720}, {{0x0, 0x0}, {0xc000632280, 0x37}, {0xc00021c6c0, 0x2, 0x2}, 0xc000390060}, ...)
        github.com/compose-spec/compose-go/[email protected]/loader/loader.go:326 +0xd8
github.com/compose-spec/compose-go/v2/cli.(*ProjectOptions).LoadProject(0xc00057a000, {0x2d37900, 0xc0003a9720})
        github.com/compose-spec/compose-go/[email protected]/cli/options.go:455 +0x119
github.com/docker/compose/v2/cmd/compose.(*ProjectOptions).ToProject(0xc00040bcc0, {0x2d37900, 0xc0003a9720},
{0x2d567b8, 0xc0001ad180}, {0x438ff00, 0x0, 0x0}, {0xc0001116b0, 0x2, ...})
        github.com/docker/compose/v2/cmd/compose/compose.go:326 +0x53f
github.com/docker/compose/v2/cmd/compose.(*ProjectOptions).projectOrName(0xc000116df0?, {0x2d37900?, 0xc0003a9720?}, {0x2d567b8?, 0xc0001ad180?}, {0x438ff00?, 0x6c6f72?, 0xc000111748?})
        github.com/docker/compose/v2/cmd/compose/compose.go:238 +0x8a
github.com/docker/compose/v2/cmd/compose.runStop({0x2d37900, 0xc0003a9720}, {0x2d567b8?, 0xc0001ad180?}, {0x2d694b8, 0xc00062dcc0}, {0xc00040bcc0?, 0x18?, 0x47c032?}, {0x438ff00, ...})
        github.com/docker/compose/v2/cmd/compose/stop.go:57 +0x88
github.com/docker/compose/v2/cmd/compose.stopCommand.func2({0x2d37900?, 0xc0003a9720?}, {0x438ff00?, 0xc000002380?, 0x2147a8a?})
        github.com/docker/compose/v2/cmd/compose/stop.go:46 +0x65
github.com/docker/compose/v2/cmd/compose.stopCommand.Adapt.func3({0x2d37900?, 0xc0003a9720?}, 0x2?, {0x438ff00?, 0x2d16c50?, 0x9d0d69?})
        github.com/docker/compose/v2/cmd/compose/compose.go:128 +0x30
github.com/docker/compose/v2/cmd/compose.stopCommand.Adapt.AdaptCmd.func5(0xc000415508, {0x438ff00, 0x0, 0x0})        github.com/docker/compose/v2/cmd/compose/compose.go:112 +0x143
github.com/docker/cli/cli-plugins/plugin.RunPlugin.func1.1.2(0xc000415508, {0x438ff00, 0x0, 0x0})
        github.com/docker/[email protected]+incompatible/cli-plugins/plugin/plugin.go:65 +0x64
github.com/docker/compose/v2/cmd/cmdtrace.Setup.wrapRunE.func2(0xc000415508?, {0x438ff00?, 0x0?, 0x0?})
        github.com/docker/compose/v2/cmd/cmdtrace/cmd_span.go:87 +0x63
github.com/spf13/cobra.(*Command).execute(0xc000415508, {0xc00062a0d0, 0x0, 0x0})
        github.com/spf13/[email protected]/command.go:1015
+0xaaa
github.com/spf13/cobra.(*Command).ExecuteC(0xc00047d208)
        github.com/spf13/[email protected]/command.go:1148
+0x46f
github.com/spf13/cobra.(*Command).Execute(...)
        github.com/spf13/[email protected]/command.go:1071
github.com/docker/cli/cli-plugins/plugin.RunPlugin(0xc0001ad180, 0xc000414608, {{0x2919a7b, 0x5}, {0x2923d27,
0xb}, {0x2cff8a0, 0x7}, {0x0, 0x0}, ...})
        github.com/docker/[email protected]+incompatible/cli-plugins/plugin/plugin.go:80 +0x145
github.com/docker/cli/cli-plugins/plugin.Run(0x2a843f8, {{0x2919a7b, 0x5}, {0x2923d27, 0xb}, {0x2cff8a0, 0x7}, {0x0, 0x0}, {0x0, ...}}, ...)
        github.com/docker/[email protected]+incompatible/cli-plugins/plugin/plugin.go:99 +0x145
main.pluginMain()
        github.com/docker/compose/v2/cmd/main.go:38 +0x14f
main.main()
        github.com/docker/compose/v2/cmd/main.go:81 +0x19e

I'm attaching a diagnostics file from when the crash happens and after trying to restore Docker to a working state.

nas-diagnostics-20260304-0629.zip nas-diagnostics-20260304-0805.zip

Nothing obvious logged that I can see. Did the issue occur right before the 1st diags were saved or before?

Sometime overnight, but this is also not the first time I ever see it happen.

I've tried to debug things myself quite a number of days before coming to this.

I got a new memory module I'm going to test, but I'm not confident it'll solve anything.

This particular machine is composed of the motherboard my previous unRAID build used + the CPU and memory my proxmox host used, but I've started using a single RAM stick to try and rule out the RAM being to blame here.

My first recommendation would be to delete the Docker folder and create an image instead. I've seen many times some weird issues with Docker folders.

The only thing I haven't tried is switching to an i

9 minutes ago, JorgeB said:

My first recommendation would be to delete the Docker folder and create an image instead. I've seen many times some weird issues with Docker folders.

Even when using bog standard stuff like a regular btrfs mirror/single disk?

I wonder why that would be the case, if so, as a docker folder is the default way of doing it for any Linux-based system I've ever seen other than unRAID.

The image is just mounted as a volume containing the filesystem, after all, isn't it?

I'd understand if there was a difference in the driver or something else, but it sounds more like there's some weird bug in either a filesystem or something else that is "accidentally" worked around when using an image, I guess?

2 hours ago, andrebrait said:

Even when using bog standard stuff like a regular btrfs mirror/single disk?

Yep, a Docker folder on any type of storage can have issues in my experience, and typically strange ones without anything being logged on the syslog.

I get that it might indeed be the case, but think about it...

• You are storing an image file...

• In a file system...

• With a file system inside...

• And you're mounting that file system...

• So every write, mount, etc., go through the file system inside the image and then the file system in the actual storage medium...

If anything, given I'm using btrfs (which is the default filesystem for images in Docker in unRAID), it should only increase the chances of some weird stuff happening, because all the image would accomplish is writing to btrfs twice (once in the image, which then gets written to my btrfs filesystem) instead of once (the filesystem itself).

So either it's some btrfs bug that's being accidentally worked around by using the image (which is a "clean" btrfs filesystem); or there's something really funky going on specifically with unRAID or how Docker is being built there.

I run Docker on a lot of distributions and they're all just using standard folders.

That includes production deployments at enterprise scale 😅

Well, admittedly, none of them run Slackware, so who knows, but it's quite weird from any point of view to think the folder can cause issues like this.

Maybe some order of initialization stuff is somehow borked?

Idk, but I guess the unRAID devs really should take a look at this.

Btw, I don't think this is a folder issue. I guess it's RAM yet again.

It would be the second batch of Crucial RAM I get (with Micron ICs, of course) that manage to pass every conceivable memory test, but crash the system at random.

@JorgeB my RAM failed after the 3rd and 5th passes of memtest86+ (ver 8.00, so a bit newer than what ships with unRAID, though I don't think this matters, but mentioning it for the sake of completeness).

It seems the guideline out there is that memtest86+ requires at least 8 passes to be truly indicative of stability.

Since my motherboard runs my RAM and the memory controller at non-factory specs by default (go figure...) I'm now trying that to see if the source of the instability is that or the RAM itself.

CPU: Intel Core i7-11700

Motherboard: ASUS PRIME Z590M-PLUS

RAM: 2x 32GB Crucial (Micron) DDR4-3200 CT32G4DFD832A.M16FF

For the 11th gen, Intel dictates only their i9 K/KF CPUs can run DDR4-3200 at 1:1 RAM-to-memory-controller ratio. The other CPUs of the 11th gen either run 2:1 ratio for DDR4-3200 and above, or 1:1 ratio for DDR4-2933 and below.

However, most motherboards seem to default to 1:1 even at DDR4-3200 speeds which might be "stable" for desktop usage, but perhaps not stable enough for a 24/7 unRAID server.

I've manually set the speed to DDR4-2933 and the ratio to 1:1 in the BIOS and I'll see where that leads us.

Edited March 6Mar 6 by andrebrait

@JorgeB after running memtest86+ with 8 passes and attesting that the RAM settings as dictated by Intel and sadly not followed by ASUS is indeed stable, I ran into the issue again and found an interesting log line when trying to run dockerd manually:

ERRO[2026-03-09T23:47:27.577083533+01:00] failed to start container                     container=14461b57ce409f4063816b7724d63faedfacd3a0476266e0cfa838847dc85a22 error="failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during

Which led me to this:

GitHub

Docker report "error jailing process inside rootfs: pivot...

Description I packged a ubuntu22.04.5_aarch64 system to ramdisk file ,boot from PXE, installed docker 28.3.3, and then run "docker run hello-world", a issue happpend as below: root@node1:~# docker ...

And sure as heck, setting DOCKER_RAMDISK=1 and starting dockerd seems to make it work.

Now I need a way to always pass that onto docker when started by unRAID.

I'm not sure this would be an actual solution long-term, but maybe docker has a nice surprise in the recent releases (and I'm not sure whether the unRAID devs know about this): https://docs.docker.com/engine/storage/containerd

Edited March 9Mar 9 by andrebrait

Is this with a docker image or folder?

Folder in a btrfs mirror pool.

I've now switched to an image. Will update this thread if I have similar issues.

And disabling the pivot root is actually very insecure, so I scratched that idea

Using a btrfs image, same result. After a while, it goes bad.

Docker becomes unavailable. Running dockerd manually then nets me this (attached)

dockerd.txt

Please also post the diagnostics after the issue happens.

The one I posted in the first post was after it had happened. I'll get a second one, but I switched to a XFS image. Let's see how that goes...

@JorgeB here's the diagnostics after it just happened.

So far it's been reproducible in btrfs + folder, btrfs + image and xfs + image.

I think it might be that the socket proxy container might be causing the docker daemon to die somehow.

nas-diagnostics-20260311-0206.zip

I'm afraid there's nothing relevant logged that I can see, suggesting more an issue with the actual container.

Yes. I removed it and I'm now just mounting the docker socket onto Traefik and Authentik.

Since the crash pretty much always happens in a matter of days, if this setup endures (or if I switch to a different proxy, like the original Tecnativa or the one by wollomatic), then I'll report it as a bug to the linuxserver socket-proxy devs.

No crashes since removing the linuxserver.io's socket-proxy containers.

Gonna try tecnativa or wollomatic and see what that gets me.

It's still running rock solid.

I also moved it back to a docker folder as that's more convenient and faster for me and so far I have not experienced a single crash.

So yes, the result seems to be that linuxserver's socket-proxy was causing dockerd to crash.

Hi,

I'm facing similar symptoms lately. I'm not sure if I have the same root cause, but I end up with no containers running and having to reboot the whole server because of a “docker image in use” error when trying to restart the Docker service from the WebUI.

In my case, the docker.log crash seems to be related to portmapper. I'm not using the alternate Docker proxy.

I don't have the full diagnostics files right now because I didn't collect them before rebooting. I'll post them after the next crash.

docker.log

I had the crash yesterday without the proxy, so now I tried to get everything off the docker socket. Let's see...

Let me check your logs.

I just had the crash and checked my docker.log, but it doesn't seem like it has a lot in common with yours.

docker.log

It keeps crashing here every 24–48 hours. I have no clue what could be causing it, and I'm not aware of having changed anything recently. I also wonder why there aren’t more people affected by this problem.

I'm running:

Unraid 6.12.14

Docker version 24.0.9, build 2936816

And this is my container list, in case you can find something in common:

REPOSITORY_______________________________TAG_________IMAGE_ID_______CREATED_________SIZE

binhex/arch-minidlna_____________________latest______ba4560c4ba57___5_months_ago____1_27GB

cyfershepard/jellystat___________________latest______4f1399257ec0___5_weeks_ago_____809MB

germannewsmaker/myspeed__________________latest______6c1fe29ccfd7___22_months_ago___188MB

ghcr_io/goauthentik/server_______________2025_8_1____650da939c425___6_months_ago____1_11GB

ghcr_io/mainfrezzer/adguardhome__________latest______3d02f027cec0___5_days_ago______123MB

jc21/nginx-proxy-manager_________________latest______e3f9fd85ccab___3_weeks_ago_____1_14GB

jlesage/handbrake________________________latest______6bec325104a9___36_hours_ago____631MB

jlesage/jdownloader-2____________________latest______26f1b6cc8f0f___38_hours_ago____426MB

lscr_io/linuxserver/deluge_______________latest______664c1c1f0f60___6_days_ago______147MB

lscr_io/linuxserver/fail2ban_____________latest______d53ff225da95___3_days_ago______77_4MB

lscr_io/linuxserver/jellyfin_____________latest______0803882db4eb___13_days_ago_____840MB

lscr_io/linuxserver/mediaelch____________latest______c51019dc52a9___45_hours_ago____2_57GB

lscr_io/linuxserver/plex_________________latest______33a8f98f8f05___13_hours_ago____371MB

lscr_io/linuxserver/sonarr_______________latest______ddf896fd2d36___9_days_ago______206MB

lscr_io/linuxserver/tautulli_____________latest______82026c0d05e5___3_days_ago______146MB

migalmoreno/tubo-backend_________________latest______55e7bff49d8b___6_weeks_ago_____661MB

migalmoreno/tubo-bg-helper_______________latest______ebeb46067fcf___6_weeks_ago_____1_67GB

migalmoreno/tubo-frontend________________latest______b7188d5cea63___6_weeks_ago_____67_5MB

ngosang/amule____________________________latest______016ac5d1385e___4_months_ago____38MB

postgres_________________________________16-alpine___108b27c919e6___2_weeks_ago_____276MB

postgres_________________________________17__________f31394cb50b3___2_weeks_ago_____453MB

qmcgaw/ddns-updater______________________latest______f85c951aea51___2_months_ago____13_2MB

quay_io/oauth2-proxy/oauth2-proxy________latest______42f956651e34___2_weeks_ago_____40_6MB

redis____________________________________latest______c234a24851ba___2_weeks_ago_____140MB

xavierh/goaccess-for-nginxproxymanager___latest______22a4360f1376___3_months_ago____140MB

Edited March 16Mar 16 by granjerox

Update on my case (last crash, March 16):

Had another crash with the same symptoms. This time I was able to recover Docker without a full reboot by manually remounting the btrfs loop device and restarting the daemon:

umount -l /var/lib/docker
losetup -d /dev/loop2
killall -9 dockerd containerd containerd-shim-runc-v2 docker-proxy
sleep 3
mount /dev/loop2 /var/lib/docker
/etc/rc.d/rc.docker start

The docker.log shows the daemon terminated with a full goroutine dump. Two goroutines stand out:

1. A CopyToPipe goroutine blocked indefinitely on a container stdio fifo:

github.com/containerd/fifo.(*fifo).Read
github.com/docker/docker/container/stream.(*Config).CopyToPipe.func1.1()

2. A libnetwork.(*Resolver) goroutine blocked on a UDP read:

github.com/miekg/dns.(*Server).serveUDP
github.com/docker/docker/libnetwork.(*Resolver).Start.func2()

Attaching full diagnostics this time.

nighthawks-diagnostics-20260317-1733.zip

Edited March 17Mar 17 by granjerox