The 29.7.1 release doesn't seem to have been published yet, so the dind, 29, 29.7 and latest tags are still serving 29.7.0, which contains a couple of known archive-extraction regressions.
Current state
bbeb926 "Update 29 to 29.7.1" landed here on 2026-07-31 22:04 UTC.
docker-library/official-images' library/docker still pins GitCommit: 1be6a77ca8e37a1668250ed412caa56eab811c6d:
Tags: 29.7.0-dind, 29.7-dind, 29-dind, dind, 29.7.0-dind-alpine3.24, 29.7.0, 29.7, 29, latest, 29.7.0-alpine3.24
- No
Update docker PR is currently open against official-images, and docker:29.7.1-dind isn't pullable.
docker:dind is byte-identical to docker:29.7.0-dind (same manifest digest).
For reference, the 29.7.0 publish (official-images#21960) was opened about 1h45m after its corresponding source commit, which is why the current gap stood out — though I realise 2026-08-01/02 were a weekend, so this may simply be pending.
Why it matters
29.7.0 shipped go-archive v0.3.0, which regressed extraction of tar entries whose parent directory is only implied — moby/moby#53257, fixed by moby/go-archive#92 (v0.3.1) and vendored in moby/moby#53260. There's also moby/moby#53258 for the /var/run → /run symlink variant, fixed via v0.3.2 in moby/moby#53261. Both fixes are in 29.7.1.
Because dind is a floating tag, anything running Docker-in-Docker in CI picks up 29.7.0 automatically on any fresh node. In our case it broke Testcontainers, which copies a directory into a not-yet-started container via PUT /containers/{id}/archive?path=/:
com.github.dockerjava.api.exception.NotFoundException: Status 404:
{"message":"Could not find the file / in container <id>"}
A minimal reproduction, using an image where the destination's parent directory doesn't exist (mysql/mysql-server:8.0 has no /etc/mysql) and a tar containing a single directory entry etc/mysql/conf.d with no etc/ or etc/mysql/ entry:
| dind image |
PUT /containers/{id}/archive?path=/ |
docker:29.6.2-dind |
200 |
docker:29.7.0-dind |
404 Could not find the file / |
29.7.0-dind with the 29.7.1 dockerd binary swapped in |
200 |
Ask
Is the 29.7.1 publish blocked on something, or just pending the next update run? Happy to help if there's anything useful I can do — mostly wanted to flag that the dind and latest tags currently point at an engine with known data-path regressions.
The
29.7.1release doesn't seem to have been published yet, so thedind,29,29.7andlatesttags are still serving29.7.0, which contains a couple of known archive-extraction regressions.Current state
bbeb926"Update 29 to 29.7.1" landed here on 2026-07-31 22:04 UTC.docker-library/official-images'library/dockerstill pinsGitCommit: 1be6a77ca8e37a1668250ed412caa56eab811c6d:Update dockerPR is currently open againstofficial-images, anddocker:29.7.1-dindisn't pullable.docker:dindis byte-identical todocker:29.7.0-dind(same manifest digest).For reference, the
29.7.0publish (official-images#21960) was opened about 1h45m after its corresponding source commit, which is why the current gap stood out — though I realise 2026-08-01/02 were a weekend, so this may simply be pending.Why it matters
29.7.0shipped go-archive v0.3.0, which regressed extraction of tar entries whose parent directory is only implied — moby/moby#53257, fixed by moby/go-archive#92 (v0.3.1) and vendored in moby/moby#53260. There's also moby/moby#53258 for the/var/run → /runsymlink variant, fixed via v0.3.2 in moby/moby#53261. Both fixes are in29.7.1.Because
dindis a floating tag, anything running Docker-in-Docker in CI picks up29.7.0automatically on any fresh node. In our case it broke Testcontainers, which copies a directory into a not-yet-started container viaPUT /containers/{id}/archive?path=/:A minimal reproduction, using an image where the destination's parent directory doesn't exist (
mysql/mysql-server:8.0has no/etc/mysql) and a tar containing a single directory entryetc/mysql/conf.dwith noetc/oretc/mysql/entry:PUT /containers/{id}/archive?path=/docker:29.6.2-dinddocker:29.7.0-dindCould not find the file /29.7.0-dindwith the29.7.1dockerdbinary swapped inAsk
Is the
29.7.1publish blocked on something, or just pending the next update run? Happy to help if there's anything useful I can do — mostly wanted to flag that thedindandlatesttags currently point at an engine with known data-path regressions.