How to fix 'Error response from daemon: No such image: …'

Overview

Docker prints 'Error response from daemon: No such image: <name>' when the daemon cannot find the referenced image locally and cannot pull it (or you pointed at the wrong name/tag/digest). This guide shows quick fixes, diagnostics, and safe cleanup steps.

Quickstart (most cases)

1. Verify the exact image name and tag:
   • If you omit a tag, Docker uses :latest. Make sure it exists.
2. Pull the image explicitly:
   • docker pull repo/name:tag
3. If using a private registry, log in:
   • docker login registry.example.com
4. If you built the image locally, reference the local tag or re-tag it:
   • docker tag localname:latest repo/name:tag
5. If the daemon context is remote, ensure the image exists on that daemon:
   • docker context ls; docker context use default (if needed)

Minimal working example

Reproduce and fix a common typo/tag issue.

# Incorrect tag (typo) -> triggers 'No such image'
docker run --rm alpine:lates
# Fix by pulling the correct tag
docker pull alpine:latest
# Now run successfully
docker run --rm alpine:latest uname -a

Local build and run by digest or tag:

# Build a simple image
cat > Dockerfile <<'EOF'
FROM alpine:3.20
CMD ["/bin/sh", "-lc", "echo ok"]
EOF

docker build -t myapp:dev .
# Tag to a canonical name, then run
docker tag myapp:dev localhost/myapp:1.0
docker run --rm localhost/myapp:1.0

# Pin to a digest (immutable) after pulling
IMG=alpine:3.20
docker pull $IMG
digest=$(docker image inspect --format '{{index .RepoDigests 0}}' $IMG)
# Run by digest
docker run --rm ${digest}

Diagnose: name, local cache, registry, or context?

• Check what exists locally:
  • docker image ls --digests
  • docker image inspect --type image repo/name:tag
• Confirm the exact reference matches:
  • repo, optional namespace, tag (or digest). Example: ghcr.io/org/app:1.2.3 or registry:5000/app@sha256:...
• Try an explicit pull to see registry errors:
  • docker pull repo/name:tag
• Check the active Docker context (you might be pointed at a different daemon):
  • docker context ls
  • docker context use default

Common symptoms and fixes:

Common fixes with commands

• Correct typos and tags

  • docker pull library/nginx:1.27
  • Avoid assuming :latest exists; specify a versioned tag.

• Use digests for immutability

  • docker pull repo/name:tag
  • docker image ls --digests
  • docker run repo/name@sha256:<digest>

• Authenticate to private registries

  • docker login registry.example.com
  • Ensure you reference the full registry path (registry.example.com/team/app:tag).

• Clean dangling or stale references (be cautious)

  • List unused images: docker image ls -f dangling=true
  • Remove specific: docker rmi <image-id>
  • Broad cleanup: docker system prune --all --volumes (will delete unused images/containers/networks/volumes)

• Fix Docker Compose references

  • If your compose file builds an image, run: docker compose build
  • Ensure service uses either build: or image: consistently. If you renamed the image, update image: service fields.
  • Force rebuild and start: docker compose up --build

• Offline or air-gapped nodes

  • Export on source: docker save repo/name:tag | gzip > image.tar.gz
  • Import on target: gunzip -c image.tar.gz | docker load
  • Run: docker run repo/name:tag

Advanced checks

• Verify registry reachability and DNS

  • docker pull busybox:latest (sanity test against Docker Hub)
  • If corporate proxy is used, configure Docker daemon and environment to use it.

• Ensure correct platform (less common for this error)

  • A platform mismatch usually shows 'no matching manifest', not 'no such image'. Still, you can force: docker pull --platform linux/amd64 repo/name:tag

• Confirm the daemon is healthy and you have space

  • docker info (look for warnings)
  • Check disk space where Docker stores images; low space can interrupt pulls.

Performance notes

• Prefer pulling by digest to avoid re-downloading layers when tags move.
• Use a registry mirror or local cache to speed up pulls in CI/CD.
• Avoid aggressive docker system prune on shared builders; it removes cache and slows subsequent builds.
• For repeated runs, keep frequently used base images pre-pulled on nodes.
• Use docker save/load to reuse images across machines without repeated network pulls.

Pitfalls to avoid

• Assuming :latest exists. Many repos do not publish it.
• Tag drift: repo/name:1 might point to different content over time. Pin digests for reproducibility.
• Pruning blindly. docker system prune --all will delete all unused images. Review what will be removed.
• Confusing containers with images. Removing an image does not remove running containers, and vice versa.
• Wrong daemon context. Images on your laptop do not exist on a remote Docker host unless pushed/pulled or loaded there.

Step-by-step resolution checklist

1. Identify the exact reference you used (repo, tag, or digest).
2. List local images and confirm presence: docker image ls --digests
3. Pull explicitly: docker pull repo/name:tag
4. If private registry, docker login and pull again.
5. If still failing, check docker context ls and switch if needed.
6. For local builds, run with the tag you built or re-tag appropriately.
7. Optionally clean dangling images, then retry.

Tiny FAQ

• Why do I get this after reboot?

  • Your environment may have been cleaned (e.g., Desktop automatic cleanup) or you switched contexts. Re-pull or switch back.

• Compose says no such image but I built it

  • The service may reference a different image name than your build tag. Run docker compose build and ensure image: matches the tag.

• Do I need the full registry URL?

  • Yes for private registries. For Docker Hub library images, 'alpine:3.20' is fine; for others use 'docker.io/user/app:tag'.

• Can I run by image ID?

  • Yes: docker run <image-id>. Useful when names/tags were removed but the image still exists locally.