Read Docker's System State with docker info

You will finish with a safe, repeatable way to inspect the Docker client and daemon, extract useful fields for a ticket or script, and recognise the common reasons the command fails. The 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 and a Docker CLI; a running daemon is needed 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 or keep the version reported by docker version. The relevant command 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

The output has a client section followed by a server section. The server report includes the number of running, paused and stopped containers, the count of unique images, the server version, storage and logging drivers, cgroup details, runtimes, security options, kernel and operating system information, CPU and memory capacity, the Docker root directory, and registry settings. Plugins and optional daemon features can add more sections.

The image count is a count of unique images. One image referenced by several tags is not counted once per tag. Do not compare that number directly with the number of repository tags returned by an image listing.

Storage-driver fields are conditional. For example, a host using 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 is stored, 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 that 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 displayed endpoint and context list 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 merely to make a report succeed.

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

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 may contain hostnames, software versions, filesystem paths, registry configuration and security details. Store it according to your incident-handling rules and remove it afterwards if it is no longer needed. To avoid writing a file, omit the redirection and pipe to a tool that does not retain the data.

For a smaller report, select fields with a Go template. The field names below are present 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 refers to a field that is absent on a particular engine or daemon, test it against the exact versions you support before putting it in monitoring.

5. Troubleshoot without changing the host

Use this order when the report is incomplete or unexpected:

1. Run docker context show and compare the selected endpoint with the one your task is meant to inspect.
2. Run docker version to see whether the client can obtain a server version and to expose client-server API details.
3. Check the daemon service status using your operating system's service tooling, if you are authorised to do so. Reading status is safe; restarting Docker can disrupt running workloads and needs a maintenance decision.
4. Check the socket or remote endpoint permissions and network path with the host administrator. Do not broaden socket permissions or expose a TCP daemon just to make docker info work.

A report can be successful while still describing a different host than expected. The context, daemon name, server version and Docker root directory are useful cross-checks. An Insecure Registries section is also a configuration signal, 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 when retention rules allow:

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

The final command is irreversible for that local copy. Check the filename before running it, and do not replace it with a broad wildcard. If you need an audit trail, keep the file in the approved location instead of deleting it.