Problem: docker commands report Cannot connect to the Docker daemon at unix:///var/run/docker.sock / failed to connect to the docker API (can't reach the daemon) —— Trove problem library

What you will run into

docker ps reports Cannot connect to the Docker daemon at unix:///var/run/docker.sock (old wording) or failed to connect to the docker API at unix:///tmp/no-such.sock (new wording). The CLI is clearly there; it's a connection problem.

Machines that installed Docker Desktop in WSL and then use native docker are most prone - usually a leftover DOCKER_HOST points the CLI at a nonexistent socket.

Why this happens

The docker CLI talks to the daemon over a unix socket (default /var/run/docker.sock). Three root causes for failing to connect:

The path in the error is the key clue: does it point at /var/run/docker.sock (default) or somewhere else (changed by DOCKER_HOST/context)?

The docker CLI and daemon are a client-server pair: the CLI performs no container operations itself — every request goes through the unix socket as an HTTP-style API call, which is why the error is always "cannot connect" rather than "command not found".

The CLI resolves the daemon in this order: DOCKER_HOST env var → current context endpoint → default /var/run/docker.sock.

A leftover DOCKER_HOST (e.g. Docker Desktop's WSL socket path) points the CLI at a file that does not exist. Deterministic takeaway: the socket path in the error is exactly where the CLI looked — read it before acting.

Default path = daemon not running or permission problem; anything else = addressing was overridden, restore with unset DOCKER_HOST or docker context use default.

Step by step

1. Look at the error path + check env vars — Required

env | grep -i docker_host

Any output -> unset DOCKER_HOST (or export -n DOCKER_HOST) and retry. Measured: this machine had a leftover DOCKER_HOST pointing at the Desktop socket (file nonexistent); after unset, docker ps recovered - the daemon had been running all along.

2. Check the context — Required

docker context ls

See what the current * endpoint is; if misconfigured, docker context use default.

3. Socket missing = daemon not started — Required

ls -l /var/run/docker.sock

Not present -> sudo systemctl start docker (or sudo service docker start). Present but permission denied -> user not in the docker group: sudo usermod -aG docker $USER then re-login, or temporarily sudo docker ....

4. WSL + Docker Desktop mixed use — Required

Pick one: using Desktop, keep DOCKER_HOST pointing at its socket (or docker context use desktop-linux); using the native daemon, clear the Desktop-related env vars/context - don't let the two entries fight.

How to confirm it works

docker ps

Container list returns normally = recovered (measured: recovered after unset DOCKER_HOST; at repro time DOCKER_HOST=unix:///tmp/no-such-docker.sock docker ps reproduced the error exactly, exit 1).

Other environments

Symptom

docker ps / docker run etc. report can't connect to the daemon the moment they run, two wordings (version-dependent):

# Old CLI wording
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

# New CLI wording (docker 25+)
failed to connect to the docker API at unix:///tmp/no-such.sock; check if the path is correct
and if the daemon is running: dial unix /tmp/no-such.sock: connect: no such file or directory

Signs: the CLI runs; the connection is what errors (not command not found); the path in the error is the key clue - /var/run/docker.sock (default) vs elsewhere (changed by DOCKER_HOST/context); machines that installed Docker Desktop in WSL and then use native docker are most prone.

Cause

The docker CLI communicates with the daemon over a unix socket (default /var/run/docker.sock). Three root causes for failing to connect:

1. Daemon not running: native docker needs systemctl start docker (or sudo service docker start); Docker Desktop needs the app/WSL integration started;
2. Wrong socket path: DOCKER_HOST env var or docker context points at a nonexistent socket - most common in WSL: a leftover DOCKER_HOST=unix:///mnt/wsl/docker-desktop/shared-sockets/.../docker.proxy.sock (Docker Desktop path) while actually using the native daemon; or the socket path changed after a Desktop upgrade;
3. Insufficient permission: the socket's owner is root:docker (srw-rw----); non-root users not in the docker group get permission denied (the error is connect: permission denied).

Solution

1. Look at the path in the error: if it's not /var/run/docker.sock, check env vars first: env | grep -i docker_host - if present, unset DOCKER_HOST (or export -n DOCKER_HOST) and retry.
2. Check the context: docker context ls to see the current * endpoint; if misconfigured, docker context use default.
3. Confirm the socket and daemon: ls -l /var/run/docker.sock missing = daemon not started (sudo systemctl start docker / sudo service docker start); present but permission denied = user not in the docker group (sudo usermod -aG docker $USER then re-login, or temporarily sudo docker ...).
4. WSL + Docker Desktop mixed use: pick one - using Desktop, keep DOCKER_HOST pointing at its socket (or docker context use desktop-linux); using the native daemon, clear the Desktop-related env vars/context - don't let the two entries fight.
5. Verify: docker ps returning normally means recovered.

Related canonicals

Read in order: precondition -> same root / same domain / related:

• Precondition (rule out first):
• docker pull fails / mirror (precondition: daemon down -> pull fails the same way)
• Port already allocated (precondition: port errors mean the daemon is alive)
• docker exec not a TTY (precondition: exec goes through the daemon API too)
• Docker build cache not working (precondition: build also needs the daemon)
• Mount Permission denied (precondition: container starts = daemon OK; permission error is at the mount layer)

• Same root:
• Docker Desktop fails to start / orphan socket (same root: Desktop engine/socket layer; Desktop-specific cause of daemon connect failure)