Fix “Cannot connect to the Docker daemon”

Check the selected endpoint, daemon availability, and permissions in that order, with separate paths for Linux, Desktop, WSL, and remote engines.

Best practices
Illustration of server operations and troubleshooting

This error means the Docker client could not complete a connection to its selected engine. First confirm which endpoint it selected; starting a local daemon will not fix a client pointed at another socket or remote host.

docker context show
docker context ls
docker version

Inspect DOCKER_HOST, DOCKER_CONTEXT, and any command-line --host or --context option. DOCKER_HOST can point to a local Unix socket as well as a remote endpoint. Do not reset context or unset variables until you understand why they were configured.

Native Linux Engine with systemd

If the intended endpoint belongs to the system Docker service:

sudo systemctl status docker
sudo journalctl -u docker --since '10 min ago' --no-pager

For an installed service that should be running, start it with sudo systemctl start docker. Enabling it at boot is a separate policy choice, not a mandatory diagnostic step. For rootless Engine, inspect the user's service and socket instead, for example systemctl --user status docker.

A service reported as active is not complete proof of API readiness. Read startup errors, verify its listening endpoint, and retry docker version against that endpoint. Successful API output establishes connectivity, not the health of every container or subsystem.

Distinguish access from endpoint selection

In a conventional rootful setup, a socket owned by root:docker commonly grants access through the docker group. Check id and the actual socket permissions. Add only trusted users to that group, then refresh their login session; access to a rootful daemon can provide host-level control.

If sudo docker works, compare the endpoint as well as credentials. Sudo may change environment variables, home-directory configuration, and context. It is only evidence of a permissions problem when both invocations target the same intended daemon.

Desktop, WSL, and remote engines

On Docker Desktop, confirm the application and engine are ready, then check its context and diagnostics. A running UI does not guarantee engine readiness. In WSL, confirm the chosen distribution's Desktop integration or its separately installed engine; avoid confusing the two.

For SSH or TLS endpoints, check routing, authentication, certificates, and the remote daemon. Do not open unauthenticated TCP access as a shortcut.

FAQ

Did daemon.json break startup?

Check JSON syntax with python3 -m json.tool /etc/docker/daemon.json, then use dockerd --validate --config-file=/etc/docker/daemon.json where supported. Valid JSON can still contain unsupported options or conflict with service startup flags, particularly duplicate hosts settings.

Can a full disk stop the daemon?

Yes. Check the actual daemon storage filesystem, available bytes, inodes, and quotas. If the daemon is unavailable, free verified unrelated host storage or expand capacity; do not delete arbitrary files inside Docker's managed data directory.

Why does it fail only after reboot?

Check startup configuration, service failures, endpoint availability, and user-session/rootless setup. A missing boot-enable setting is one possibility, not the only cause.

See daemon troubleshooting, contexts, and Linux post-installation.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting