
Docker 29.1.4 release notes: the three bugs worth your time
If Docker on Windows ever face-planted on –network none, 29.1.4 targets that exact mess.
I’ve watched teams ignore “just a patch” releases, then spend a weekend chasing disk pressure and daemon crashes that should have died in staging. Docker v29.1.4 (tagged Jan 9, 2026 on GitHub) fixes a Windows panic, a long-path mount failure, and a pair of overlay2 cleanup bugs. It also vendors BuildKit v0.26.3.
TL;DR: should you upgrade?
Depends. Really.
Upgrade sooner if you run Docker Engine on Windows hosts, if you hit “file name too long” during mounts, or if overlay2 grows like mold even after you delete containers. If none of that sounds familiar and your hosts behave, I would still canary it, but I would not rush it into every production node on a Friday.
- Upgrade now (after a quick canary): Windows Server hosts that run
docker run --network nonein scripts or tests, or any host with unexplained overlay2 disk growth. - Upgrade soon: CI runners that do lots of image mounts, builds, and tear-down cycles.
- Probably wait: quiet Linux hosts where you already pinned a known-good Engine build and you do not need the overlay2 fixes.
What changed (with upstream breadcrumbs)
Here’s the stuff that matters, with the upstream PRs so you can read the actual diffs instead of trusting a blog post.
- Windows panic on
--network none: Docker fixes a daemon panic in Windows networking code (PR #51830). This targets the crash path people hit when they run containers with no network attached. - Long mount paths (“file name too long”): Docker changes how it names image mount layers to keep names filesystem-friendly (PR #51829). This aims at failures that show up when mount paths get deep and ugly.
- overlay2 orphan cleanup: Docker cleans up init layers when setup fails (PR #51826) and cleans up RW layers when metadata save fails (PR #51824). I like these changes because they address the failure path, not just the symptom.
- BuildKit bump to v0.26.3: Docker vendors BuildKit v0.26.3 (PR #51821). BuildKit’s own notes call out a fix around session policy metadata resolution for git attributes and image attestations. That’s narrower than “performance and security fixes,” so I’m not going to claim more than upstream does.
The Windows crash: how it shows up in real life
This bit me when a Windows host ran a test suite that spins containers up and down with isolated networking.
You run something like docker run --network none ..., the daemon panics, and suddenly your pipelines fail in a way that looks like “CI is flaky again.” In most orgs, nobody correlates it to a specific flag until the third incident review. If you have Windows Docker hosts, treat 29.1.4 as a stability patch, not a nice-to-have.
If you only take one action: canary 29.1.4 on one Windows host and run your
--network noneworkloads against it for a day.
overlay2 orphans: why disk keeps disappearing
Disk leaks don’t feel dramatic until your host hits 95% and starts killing everything.
Overlay2 issues often show up as slow-motion pain. Builds succeed, containers run, and then the filesystem fills up even though you swear you cleaned old images. These fixes focus on cleanup when layer initialization or metadata writes fail. That matters because failures happen during the worst possible time, under load, when you least want a half-created layer left behind.
- Pre-upgrade check: run
docker system dfand record the output. Do it again after the canary. You want to see disk usage stabilize, not climb. - Post-upgrade sanity check: create and remove a batch of short-lived containers, then re-check disk usage. I’m not giving you a one-liner that deletes files in
/var/lib/docker. That’s how people end up in incident chat.
How to upgrade (with a rollout style that won’t ruin your week)
Take a snapshot.
On Linux, that might mean an LVM snapshot or a VM snapshot. On Windows, that might mean a VM checkpoint if you can tolerate it. Then do a canary. Some folks skip canaries for patch releases. I do not, because I’ve seen “harmless” updates break exactly one plugin and take out a build farm.
- Check current version:
docker --version - Upgrade via your OS packaging channel: follow Docker’s official install method for your distro, then install 29.1.4. If you’re on Ubuntu 22.04 and you pin versions, the article’s apt example works, but double-check the exact package epoch/version string for your repo.
- Restart the daemon:
systemctl restart docker - Verify:
docker versionshows Server 29.1.4 on the canary host. - Test what broke before: run your Windows
--network noneworkload, your long-path mount workload, and at least one representative BuildKit build.
Known issues
Upstream does not list a “Known issues” section for this tag.
That does not mean nobody hit problems. It just means upstream didn’t publish a list on the release page. If you’re rolling this into prod, skim the GitHub issues for moby/moby around the release date, then decide how paranoid you want to be.
Official release notes
Read the upstream tag and PR list here: https://github.com/moby/moby/releases/tag/docker-v29.1.4
Other stuff in this release: dependency bumps, some vendor updates, the usual.