Read Docker's System State with docker info

docker info is your first stop when a host looks wrong: one command inspects the client and daemon together. Examples were checked with Docker Engine 29.8.1 and docker-ce-cli package version 5:29.8.1-1~ubuntu.24.04~noble. Allow about ten minutes; you need a shell, a Docker CLI, and a running daemon for the server section of the output.

1. Confirm the client you are about to use

Check the binary and package version first. These are ordinary read-only commands:

$ command -v docker
/usr/bin/docker
$ dpkg-query -W docker-ce-cli
docker-ce-cli 5:29.8.1-1~ubuntu.24.04~noble
$ docker version --format '{{json .Client}}'
{"Platform":{"Name":"Docker Engine - Community"},"Version":"29.8.1","ApiVersion":"1.56",...}

Your path and version may differ. The package query is specific to Debian-family systems, so on another distribution use its package manager instead and keep the version reported by docker version. The command itself is docker system info, with docker info as its documented alias.

2. Read the complete system report

Run the command without options:

$ docker system info

• A client section, then a server section. The server report covers running, paused and stopped container counts, the count of unique images, server version, storage and logging drivers, cgroup details, runtimes, security options, kernel and OS information, CPU and memory capacity, the Docker root directory, and registry settings. Plugins and optional daemon features can add more.
• Image count is unique images. An image referenced by several tags is not counted once per tag, so do not compare it directly with a repository-tag listing's row count.
• Storage-driver fields are conditional. A host on an overlay-based driver may show a backing filesystem or snapshotter detail that is absent elsewhere. The Docker root directory tells you where daemon data lives, not where an individual container's writable files should be edited.

3. Separate a client problem from a daemon problem

The command needs to contact a Docker daemon. Run it as your normal account:

$ docker info
Client:
 Context:    default
...
Server:
 Containers: 48
 ...

Exact numbers and fields are host-specific. A complete report with both sections shows the selected client context reached a daemon. If you see client information followed by a connection error, the CLI is installed but the daemon endpoint is unavailable: the daemon is stopped, the socket is inaccessible, or the selected context points somewhere unexpected.

Check the active context without changing it:

$ docker context show
default
$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

The endpoint and context list shown here are examples of the shape, not values to copy blindly. If an automation job uses DOCKER_HOST or an explicit context, inspect that configuration before diagnosing the daemon. A context change is stateful for the CLI, so do not run docker context use just to make a report succeed.

If your account hits a permission error for the Unix socket, confirm the socket and account policy with your administrator first. Using sudo docker info may reach the root user's own client configuration and a different context, so treat that as a separate, clearly labelled test.

4. Produce machine-readable output

Use the format option when a script or incident record needs stable data rather than the human report. The special value json prints the complete report as one JSON object:

$ docker info --format '{{json .}}' > docker-info.json
$ python3 -m json.tool docker-info.json > /dev/null
valid JSON output

The redirection creates or replaces docker-info.json in the current directory. That file can contain hostnames, software versions, filesystem paths, registry configuration and security details, so store it under your incident-handling rules and remove it afterwards if it is no longer needed. Skip the redirection and pipe to a tool that does not retain the data if you want to avoid writing a file at all.

For a smaller report, select fields with a Go template. These field names exist in the installed command's JSON output:

$ docker info --format 'server={{.ServerVersion}} os={{.OperatingSystem}} root={{.DockerRootDir}} containers={{.Containers}} images={{.Images}}'
server=29.8.1 os=Ubuntu 24.04.5 LTS root=/var/lib/docker containers=48 images=32

Values will differ. Keep the template in single quotes in a POSIX shell so the braces reach Docker unchanged. If a template references a field absent on a particular engine or daemon, test it against the exact versions you support before it goes into monitoring.

5. Troubleshoot without changing the host

1. Compare contexts. Run docker context show and check the selected endpoint against the one your task is meant to inspect.
2. Try the version handshake. Run docker version to see whether the client can obtain a server version and expose client-server API details.
3. Check the daemon service, if you can. Use your OS's service tooling; reading status is safe, but restarting Docker can disrupt running workloads and needs a maintenance decision.
4. Check the socket or endpoint with the admin. Do not broaden socket permissions or expose a TCP daemon just to make docker info work.

A report can succeed while still describing a different host than you expected. The context, daemon name, server version and Docker root directory are useful cross-checks. An Insecure Registries section is a configuration signal too, not an instruction to add a registry: do not copy it into daemon configuration without understanding the security consequence.

6. Clean up the captured report

If you created the example file, inspect it, send it through the approved channel, then remove it once retention rules allow:

$ test -s docker-info.json && echo 'report is non-empty'
report is non-empty
$ rm -- docker-info.json