Docker Error Reference

Docker splits error reporting between two processes. The CLI parses commands, builds API requests, and prints everything the daemon sends back, while the daemon performs the actual work of pulling images, managing storage, wiring networks, and starting containers through an OCI runtime. A single command can therefore fail in any of these layers, and the message text usually names which one spoke.

Most Docker errors arrive wrapped in a shared envelope, such as the daemon's error response prefix or a build solver's failed-to-solve headline, with the real condition appended after it. That condition comes from a subsystem with its own vocabulary: registries answer with manifest and authorization conditions, the port allocator reports bind conflicts, and runtimes report process-level failures. Reading past the envelope is the core skill for interpreting this family.

FixerCode documents 28 Docker messages across 1 model, grouped by failure layer: daemon connectivity, registry pulls and pushes, published-port conflicts, storage and volumes, networks, container lifecycle states, OCI runtime refusals, and BuildKit or Compose build-time failures. Each entry explains which layer produced the message and how it differs from its closest siblings.