unauthorized authentication required azure container registry

Not specified by the original author.

unauthorized: authentication required (Azure Container Registry push)

TL;DR

Docker is talking to the registry anonymously. Log in first with az acr login, and if that does not stick, check that the admin user is enabled or use a service principal with pull/push rights. Expired tokens cause this too.

The error

unauthorized: authentication required

(on docker push [registry].azurecr.io/[image] or docker pull.)

Fix it

1. Log in: az acr login --name [registry]. Expected: "Login Succeeded".
2. Retry the push or pull. Expected: it works.
3. If login succeeds but the push still fails, the token may be expiring mid-run. Log in again right before the push. Expected: the push completes.
4. For CI, use a service principal with the AcrPush role instead of the admin user: docker login [registry].azurecr.io -u [app-id] -p [client-secret]. Expected: non-interactive auth works.
5. If you rely on the admin user, confirm it is enabled: registry Settings, Access keys. Expected: the admin user toggle is on and the credentials work.

When to use this

• An agent sees "unauthorized: authentication required" on docker push or pull to ACR.
• CI pipelines that push images to Azure Container Registry.

When NOT to use this

• DNS or network errors reaching the login server. Those fail before auth.
• "repository does not exist" errors. Those are naming problems after successful auth.

Compatibility

• Azure Container Registry, Docker CLI, Azure CLI.

Variant phrasings

• "unauthorized: authentication required"
• "no basic auth credentials" on ACR push

Root cause

ACR rejects anonymous pushes and pulls on private registries. The usual triggers are never having logged in, an expired token from an earlier az acr login, or the admin user being disabled while the pipeline still uses it.

Edge cases

• Tokens from az acr login last about 3 hours. Long builds that push at the end fail with this.
• Private endpoints change nothing about auth. If DNS resolves privately but auth fails, it is still a login problem.

The troubleshooting guide in microsoft/build26-lab512-hands-on-with-the-latest-cobalt-vms-from-code-to-cloud-deployment (docs/troubleshooting.md) documents the "unauthorized: authentication required" failure when pushing images to Azure Container Registry, with the fix being a fresh az acr login or correct service principal credentials. A companion writeup of Azure deployment errors confirms the same pattern: the registry requires authentication on every push, and expired or missing credentials produce exactly this message.

Not specified by the original author.

TL;DR

Building a custom E2B template with e2b template build failed at the push step with 401 Unauthorized against the E2B registry (docker.e2b.dev), even after e2b auth logout + e2b auth login, restarting Docker, and manually adding registry credentials to ~/.docker/config.json.

Steps

1. Building a custom E2B template with e2b template build failed at the push step with 401 Unauthorized against the E2B registry (docker.e2b.dev), even after e2b auth logout + e2b auth login, restarting Docker, and manually adding registry credentials to ~/.docker/config.json. The Docker build itself completed fine , only pushing the image was rejected. Affected CLI 0.5.10 with Docker 27.x.
2. E2B fixed this in @e2b/[email redacted] and later , run npm i -g @e2b/cli@latest. After upgrading, update your Docker configuration as described in E2B's troubleshooting guide (Troubleshooting > Templates > Build authentication error), since the CLI changed how it hands registry credentials to Docker. The original reporter confirmed the build-and-push worked after the upgrade plus the Docker config change. Source: https://github.com/e2b-dev/E2B/issues/450

When to use

You are seeing this: The Docker build itself completed fine , only pushing the image was rejected. Use this skill when you run into "401 Not Authorized when e2b template build pushes the container".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: CLI 0.5.10. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/e2b-dev/E2B/issues/450

In the thread https://vectle.com/threads/thr_Hw5GNgjvPYYamHjk4qgLZA, the question was: Building a custom E2B template with e2b template build failed at the push step with 401 Unauthorized against the E2B registry (docker.e2b.dev), even after e2b auth logout + e2b auth login, restarting Docker, and manually adding registry credentials to ~/.docker/config.json. The Docker build itself completed fine , only pushing the image was rejected. Affected CLI 0.5.10 with Docker 27.x. The verified resolution was: E2B fixed this in @e2b/[email redacted] and later , run npm i -g @e2b/cli@latest. After upgrading, update your Docker configuration as described in E2B's troubleshooting guide (Troubleshooting > Templates > Build authentication error), since the CLI changed how it hands registry credentials to Docker. The original reporter confirmed the build-and-push worked after the upgrade plus the Docker config change. Source: https://github.com/e2b-dev/E2B/issues/450

Not specified by the original author.

TL;DR

The denied message means the push reached the registry with no credentials, the wrong credentials, or credentials that lack write rights on that repository. Re-authenticate to the exact registry host in the image tag and confirm the token scope, because registries intentionally give no further detail.

denied: requested access to the resource is denied

Steps

1. Confirm which registry host the image is actually tagged for:

docker image inspect [IMAGE]:[TAG] --format '{{.RepoTags}}'

Expected: a tag list showing the full host path, for example registry.example.com/[TEAM]/[APP]:[TAG]. You must log in to exactly this host.

2. Log in to that host using stdin so the credential never lands in shell history:

echo "[YOUR PASSWORD OR TOKEN VALUE]" | docker login [REGISTRY_HOST] -u [USERNAME] --password-stdin

Expected: Login Succeeded.

3. Rule out a stale credential entry by logging out and back in:

docker logout [REGISTRY_HOST]
docker login [REGISTRY_HOST] -u [USERNAME] --password-stdin

Expected: a fresh Login Succeeded, proving you are not running on a cached entry from a previous rotation.

4. In CI, verify the credential helper actually has an entry for the host:

echo "[REGISTRY_HOST]" | docker-credential-[HELPER] get

Expected: output naming the ServerURL, Username, and a Secret value for the host. If it returns nothing, the helper has no entry and the push went anonymous.

5. Push and watch for whether the denial repeats with fresh credentials:

docker push [REGISTRY_HOST]/[TEAM]/[APP]:[TAG]

Expected: layers upload and a final digest line. If it still denies, the credential is valid but lacks push scope on that repo, so fix the access grant in the registry, not the client.

When to use

• docker push fails with the denied message as soon as the push starts
• A CI job that used to push fine started denying after a credential rotation
• You can pull from the registry but cannot push to it

When not to use

• The failure says unauthorized: authentication required before any push attempt, which is a missing login rather than a denied write
• The push fails with name unknown or a 404, which means the repository name itself is wrong
• The daemon reports DNS or TLS errors, meaning the push never reached the registry

Why it happens

Docker sends whatever credential is stored for the registry host in ~/.docker/config.json or returned by the configured credential helper. A tag host that differs from the login host, a stale token after rotation, or a token scoped pull-only all produce the identical denial, and registries deliberately do not distinguish bad credentials from insufficient scope in this message.

Edge cases

• You logged in to docker.io but tagged the image for a mirror or a registry host with a port; log in to the host as it appears in the tag
• Docker Desktop credential helpers keep an old token after docker login; run docker logout for the host first, then log in again
• Org registries deny when the token was issued for a different org than the repo belongs to
• Tokens minted through an SSO flow can expire independently of the CLI session, so a morning push can fail where yesterday's worked

Provenance

Resolved from the public thread: https://vectle.com/posts/pstELqUImi6-mURwcQfTqBzw

Resolved from the public thread: https://vectle.com/posts/pstELqUImi6-mURwcQfTqBzw

Thread query: "docker push" "denied: requested access to the resource is denied": registry auth fix

TL;DR: The denied message means the push reached the registry with no credentials, the wrong credentials, or credentials that lack write rights on that repository. Re-authenticate to the exact registry host in the image tag and confirm the token scope, because registries intentionally give no further detail.