Every so often, I run into one of those problems that reminds me why I like to keep my systems boring. This week’s adventure? Docker installed via Snap on an Ubuntu host that happened to require a fairly sophisticated ZFS setup and multiple mounts. I should also clarify that while Docker was the issue here, I was doing my application administration via Dokku which of course is built on Docker. On paper, this shouldn’t be interesting. Install Docker, deploy Dokku, add Postgres, make my mounts, setup ZFS, configure my cron jobs and voila! Well, not if your Docker came from Snap which I didn’t know at the time; it was already installed on the box.
Everything looked fine until I tried to setup up my complicated syncing volumes. Dokku could spin up apps, but Postgres containers behaved OK at first, but then… oddly. Mounts wouldn’t persist, permissions got weird, and filesystem operations failed in subtle ways. Sometimes a container would just refuse to start. Other times, Postgres data directories would silently fail to initialize. It smelled like a permissions or mount issue, but the logs weren’t very illuminating; just a bunch of “permission denied” on mundane workaday file-system operations. If you’ve used Snap before, you can probably guess what came next, but unfortunately, I didn’t. Instead, I spent a few hours chasing this bug like the Wiley Coyote only for it to “Beep Beep” and dash Road Runner style.
The Snap version of Docker isn’t the same as the traditional docker-ce package. It runs under Snap’s confinement model, which limits what parts of the filesystem it can touch. That includes certain bind mounts, custom datasets, and — you guessed it — ZFS-backed volumes; in fairness to Snap, they’d consider this one of the core features of Snap. If you’re running a simple container or two, you likely would never notice, but when you started doing complicated things with mounts and ZFS in particular, you’re going to have some issues. There’s actually a pretty vibrant discussion on this very issue on Canonical’s official Snap forums.
After an hour or two of chasing ghosts, I ripped out the Snap version. Then installed the real thing – IE the deb package. One reboot later, it was magic, everything started working again. Volumes mounted correctly, Dokku behaved as expected, and Postgres stopped throwing fits. Snaps are great in theory: sandboxed, auto-updating, isolated, but when you’re dealing with low-level tooling — especially something that orchestrates filesystems, networks, and kernel namespaces — that isolation becomes a liability. Dokku, Postgres, and ZFS all assume Docker has full control of its environment; frankly, so did I. The Snap version simply doesn’t. It’s not a bug, it’s a design choice — just one that’s incompatible with this particular complex use-case. To be fair to Snap, the moral of the story isn’t “Snaps are bad.” It’s that layers of abstraction leak, and when they do, you want to be close enough to the metal to fix it. Snaps do make a ton of sense on the desktop for many applications. But on the server, for real complex workloads, “boring old apt” is the more reliable tool.
Let me know what you think on LinkedIn or X and if you have trapped legacy data that you want to bring into the modern would of data lakes and BI tools or need some custom dev done, checkout Alice.
