Skip to main content
DevOps Insightsguides & answers

Containers · intermediate

docker push Failing Since Docker 29.7? Two Causes

Short answer

Docker 29.7 brought in a newer BuildKit and a newer containerd, and each changed how pushes behave. blob unknown to registry with your image's own digest means the registry rejected the build's attestation; rebuild with BUILDX_NO_DEFAULT_OCI_ARTIFACT=1. net/http: timeout awaiting response headers on a big layer means the registry took more than 30 seconds to confirm it; push from the classic image store or make layers smaller.

N
Neeraj Jha
3 min read
On this page · 3 sections
Diagram of Which push failure is yours?: 1. Read the error, 2. blob unknown, image digest, 3. Fix one, 4. timeout awaiting headers, 5. Fix two.

Failure one: blob unknown to registry

From BuildKit 0.32, which Docker 29.7 bundles, the provenance record pushed next to your image (the attestation) is stored as an OCI artifact that points at the image. BuildKit uploads that record before the image itself. The OCI distribution spec says registries must accept that order. Some do not, GitLab's among them, and they answer:

text
error from registry: blob unknown to registry - sha256:…

The giveaway is the digest: it is your image manifest's digest, the one the build log prints as exporting manifest, not a layer's. The fix keeps your provenance and changes only its format:

bash
export BUILDX_NO_DEFAULT_OCI_ARTIFACT=1   # Buildx 0.36.1 or later
docker build -t registry.example.com/app:1.0 .
docker push registry.example.com/app:1.0

Rebuild after setting it; an image already built keeps the format it was built with.

Failure two: timeout awaiting response headers

containerd 2.3, which Docker uses for its default image store since 29.7, gives a registry 30 seconds to start answering each request. Registries that copy or scan a large layer before confirming it, such as Nexus or Harbor on slow storage, take longer for multi-gigabyte layers. The upload reaches 100%, waits about 30 seconds, and fails on the same layer every retry.

Which push failure is yours?

1. Read the error. Two different messages, two different changes in Docker 29.7.

1 / 5

The limit is not configurable yet. To push from the classic store, set this in /etc/docker/daemon.json and restart Docker :

json
{ "features": { "containerd-snapshotter": false } }

For a dind service, start it with --feature=containerd-snapshotter=false.

Where to go next

Both have full pages: blob unknown to registry and timeout awaiting response headers.

Tagged with

Enjoyed this article?

Get more DevOps insights delivered to your inbox.

Get new posts by email

Subscribe to get an email when a new blog post is published. Skip anytime.

No spam, unsubscribe anytime.

N

Written by

Neeraj Jha

Platform administrator and lead writer.

View all posts →

Discussion

0 comments

Sign in to join the conversation.

Be the first to comment

Start a conversation about this post

Share: