🚨 Docker Error Guide: 'denied: requested access to the resource is denied' — Fix docker push Auth

Overview

This appears at the end of a docker push when the registry authenticated you but decided you are not allowed to write to that repository:

denied: requested access to the resource is denied

The push is being rejected on authorization, not authentication — the registry knows who you are (or that you are anonymous) and has refused write access to that specific repository path. The usual cause is pushing to a namespace you do not own, or not being logged in with an account that has push rights.

Symptoms

• docker push registry.example.com/myapp:1.4.2 fails after uploading nothing, ending in denied: requested access to the resource is denied.
• Pulling public images works, but pushing your own fails.
• The push works for a teammate but not for you, or works from your laptop but not from CI.
• The tag uses a namespace that is not your account or organization.

Common Root Causes

• Not logged in to the target registry, so the push is treated as anonymous and rejected.
• Wrong namespace in the tag — pushing to library/... or another user’s/org’s account you cannot write to.
• Insufficient permissions — your account or token lacks the push/write scope on that repository.
• Repository does not exist and auto-create is off — the registry will not create the repo for your account.
• Expired or read-only token — CI credentials are valid for pull but not push.
• Pushing to the wrong registry host — the tag omits the registry, defaulting to Docker Hub instead of your private registry.

Diagnostic Workflow

Confirm exactly what tag you are pushing and to which registry:

docker image ls | grep myapp
# the first path segment is the registry; the next is the namespace

Check who you are currently authenticated as and against which registries:

cat ~/.docker/config.json      # "auths" lists the registries you have creds for

Log in to the correct registry with an account that has push rights:

docker login registry.example.com
# Username / Password (or a personal access token)

Re-tag with a namespace you actually own, then push:

docker tag myapp:1.4.2 registry.example.com/myteam/myapp:1.4.2
docker push registry.example.com/myteam/myapp:1.4.2

If it still fails, verify the token’s scope by checking the registry’s UI/API for write permission on myteam/myapp, and inspect the daemon log for the auth exchange:

journalctl -u docker --since '5 min ago' | grep -i 'denied\|auth'

Example Root Cause Analysis

A CI job built myapp:1.4.2 and pushed to registry.example.com/myapp:1.4.2, failing with denied: requested access to the resource is denied. The same image pushed fine from a developer laptop.

The difference was the namespace. On the laptop the engineer had tagged the image under their team org; CI used the bare myapp path, which on this registry maps to a top-level namespace the CI service account could not write to. cat ~/.docker/config.json in CI confirmed the runner was authenticated, so this was authorization, not login.

The fix was to tag with the team namespace the CI token had push rights to:

docker tag myapp:1.4.2 registry.example.com/myteam/myapp:1.4.2
docker push registry.example.com/myteam/myapp:1.4.2

The push succeeded once the repository path matched a namespace the token was scoped to write.

Prevention Best Practices

• Always tag images with the full registry/namespace/name:tag path so pushes go to the intended repository.
• Use scoped push tokens (robot/service accounts) in CI and confirm they have write access to the target namespace.
• Create the repository ahead of time if the registry does not auto-create, and grant the pushing identity write permission.
• Keep docker login non-interactive in CI with --password-stdin and short-lived tokens.
• Standardize your image naming and publish flow using the Docker stack guide and lint builds with the Dockerfile validator.

Quick Command Reference

docker image ls | grep myapp                 # verify registry + namespace in the tag
cat ~/.docker/config.json                     # which registries are you logged into?
docker login registry.example.com            # authenticate with a push-capable account
docker tag myapp:1.4.2 registry.example.com/myteam/myapp:1.4.2
docker push registry.example.com/myteam/myapp:1.4.2

Conclusion

denied: requested access to the resource is denied is an authorization failure on docker push: the registry will not let your identity write to that repository path. Check that you are logged in with an account that has push rights, and — most often — that the image is tagged under a namespace you actually own. Re-tag with the full registry/namespace/name path and push again. If it persists, the fix lives in the registry’s permission settings, not your Docker client.