Docker Error Troubleshooting — The Complete Guide
Most Docker time is spent fighting the same handful of errors. This is the map: what each one means, the command that reveals the cause, and the fix.
Key takeaways
- Most Docker time is spent fighting the same handful of errors.
- This is the map: what each one means, the command that reveals the cause, and the fix.
On this page
Docker Error Troubleshooting — The Complete Guide#
Docker is simple until it isn't. The moment something breaks, you get a terse one-line error and a container that either won't start, exits instantly, or refuses to talk to anything. The good news is that almost every Docker problem is one of a small, well-known set. This guide is the map: for each common error it explains what actually went wrong, the command that reveals the cause, and where the fix lives.
The universal first move, before any specific error, is to ask Docker what happened:
docker ps -a # is it running, or Exited with a code?
docker logs <container> # what did it print before dying?
docker inspect <container> # config, mounts, exit code, OOMKilled flag
docker events # live stream of what the daemon is doing
Nine times out of ten the exit code and the last few log lines tell you everything.
"I can't even talk to Docker"#
Two errors stop you before you start:
- Permission denied on the socket: "Got permission denied while trying to connect to the Docker daemon socket." Your user isn't in the
dockergroup. Fixed in Docker permission denied. - Cannot connect to the daemon: "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" The daemon is stopped or you're pointed at the wrong host. Fixed in cannot connect to the Docker daemon.
"The container won't stay up"#
- Container exits immediately: it starts, then
docker ps -ashows Exited. Usually the main process finished or forked into the background, so PID 1 exited. Walked through in container exits immediately. - Exit code 137 (OOM): the container was killed for exceeding its memory limit. Covered in Docker exit code 137. (The Kubernetes equivalent is OOMKilled.)
- exec format error: you're running an image built for a different CPU architecture (arm64 image on amd64 or vice versa). Fixed in Docker exec format error.
"It won't build or bind"#
- Port is already allocated: another process or container already holds the host port. Fixed in port already allocated.
- No space left on device: Docker filled the disk with images, layers, volumes, and build cache. Reclaimed in no space left on device.
- Slow or broken build cache: rebuilds that redo everything, or a cache that serves stale layers. Fixed in Docker build cache, and a tight .dockerignore prevents half of it.
- Compose failures: env vars not interpolating,
depends_onnot waiting for readiness, network name clashes. Covered in docker-compose errors.
The mental model#
Docker problems cluster into four buckets: you can't reach the daemon (socket/permissions), the container won't stay up (PID 1 / OOM / arch), it won't build or bind (cache / disk / ports), or Compose is wiring things wrong. Naming the bucket from docker ps -a plus the exit code turns a cryptic message into a short checklist. Once the basics are solid, harden the image (multi-stage builds, image hardening) so there's less to go wrong.
The call we'd make#
Read the exit code and the last log lines first; they answer most of these in seconds. Learn the four buckets so a new error slots into one before you start guessing. Each linked guide is the fast path for a specific failure. Docker rewards a small amount of memorization: the same dozen errors will follow you across every project, and turning each into a reflex is what separates a five-minute fix from a lost afternoon.
Get the DevOps Troubleshooting Cheat Sheet
Subscribe and get our free one-page reference for the errors that eat an afternoon — CrashLoopBackOff, OOMKilled, Terraform state locks, and more — plus new guides as we publish them.
More from DevOps
Explore more articles in this category
Kubernetes vs Docker Swarm in 2026: Is Swarm Still Worth It?
Swarm lost the orchestration war years ago, but it's still shipping and still simpler. Here is what that simplicity actually buys you, and what it costs.
Best Kubernetes IDE and GUI Tools in 2026
kubectl is fine until you're juggling five namespaces across three clusters. These are the tools that make that manageable, compared.
Chef vs Puppet vs Ansible: Configuration Management in 2026
One is agentless and Python-based, the other two run a persistent agent and a domain-specific language. The architecture difference matters more than the syntax.
You might have missed
Evergreen posts worth revisiting.