Cannot Connect to the Docker Daemon (tested)

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? means the docker CLI could not reach dockerd at the address it tried. It is a client-side connection failure, not a daemon crash report. We reproduced it safely by pointing the CLI at a socket path and ports that do not exist, without touching the real daemon.

1. What this error means

The docker command is a thin client. Every command, including docker ps, opens a connection to dockerd at whatever address is configured: by default the unix socket /var/run/docker.sock, or a DOCKER_HOST you set, or a docker context. If nothing answers at that address, the CLI prints a "cannot connect" error and exits 1. It says nothing about why the daemon isn't there — stopped, not installed, wrong socket, wrong permissions, or wrong host are all the same symptom from the client's point of view.

2. Our test setup

We did not stop or touch the real Docker daemon on our box (it has live containers). Instead we made the CLI look in the wrong place by overriding DOCKER_HOST for single commands, which only affects that command, not the daemon:

DOCKER_HOST=unix:///tmp/guide-dockerdaemon/nonexistent.sock docker ps
DOCKER_HOST=tcp://127.0.0.1:1 docker ps
DOCKER_HOST=tcp://127.0.0.1:19999 docker ps

We ran this with Docker Engine 29.8.1 and Docker Compose v5.5.1. A plain docker ps with no override, run right after, still listed our real containers normally — confirming the daemon itself was never affected.

3. Results: the exact errors, side by side

Command	Address tried	Output	Exit code
docker ps	unix:///tmp/…/nonexistent.sock	failed to connect to the docker API at unix:///tmp/…/nonexistent.sock; check if the path is correct and if the daemon is running: dial unix /tmp/…/nonexistent.sock: connect: no such file or directory	1
docker ps	tcp://127.0.0.1:1	Cannot connect to the Docker daemon at tcp://127.0.0.1:1. Is the docker daemon running?	1
docker ps	tcp://127.0.0.1:19999	Cannot connect to the Docker daemon at tcp://127.0.0.1:19999. Is the docker daemon running?	1
docker -H tcp://127.0.0.1:19999 ps	tcp://127.0.0.1:19999	identical wording to the DOCKER_HOST env var case above	1
docker info	unix:///tmp/…/nonexistent.sock	prints the Client block (version, plugins) fine, then under "Server:" the same "failed to connect to the docker API…" line as docker ps	1
docker version	unix:///tmp/…/nonexistent.sock	prints the Client block fine, then the same "failed to connect to the docker API…" line, no Server block at all	1
docker compose -p forever-test ps	unix:///tmp/…/nonexistent.sock	byte-for-byte the same "failed to connect to the docker API…" line as docker ps	1
docker compose -p forever-test ps	tcp://127.0.0.1:19999	byte-for-byte the same "Cannot connect to the Docker daemon at tcp://…" line as docker ps	1

Two things stand out. First, on this CLI version the unix-socket failure and the TCP failure use different wording: the socket case says "failed to connect to the docker API at…", the TCP case says the older, shorter "Cannot connect to the Docker daemon at…". If your search brought you here for the classic "Cannot connect to the Docker daemon at unix:///var/run/docker.sock" phrasing specifically, note that a current Docker CLI (29.8.1) only prints that exact classic shape for TCP addresses; for a missing unix socket it now prints the longer "failed to connect to the docker API" message with the underlying dial unix …: connect: no such file or directory reason attached. Older CLI versions used the classic wording for both; expect either shape depending on your installed version.

Second, port 1 (a privileged port nothing was listening on) and port 19999 (an ordinary unused port) produced the identical message. The CLI does not distinguish "nothing listens here" from "you'd need privilege to bind here" — both are just a failed TCP connect from the client's side, so you cannot tell port-privilege issues apart from plain "nothing running" by the wording alone.

4. docker compose behaves exactly like docker

We confirmed docker compose ps (the plugin, invoked via docker compose -p <project> ps) reports the exact same connection error, word for word, as plain docker ps, for both the unix-socket and the TCP case. That is expected: the compose plugin talks to the daemon through the same client library docker itself uses. There is no separate "compose can't connect" message to learn — fixing the connection fixes both.

5. Permission-denied (per the Docker docs, not measured here)

We could not reproduce this one safely: our test account is already in the docker group, and reproducing a permission failure would mean either removing that group membership or using sudo to break the socket's permissions, both of which we avoided. Per the Docker docs, a user who is not in the docker group and runs a plain docker ps against the real socket sees something like:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock:
Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.51/containers/json":
dial unix /var/run/docker.sock: connect: permission denied

This is a different failure from "cannot connect": the socket exists and the daemon is running, but your user lacks read/write access to it. The fix is to add your user to the docker group (sudo usermod -aG docker $USER, then log out and back in) rather than prefixing every command with sudo.

6. Rootless Docker and Docker Desktop (per the docs, not measured)

This box runs standard Linux dockerd as a system service, so we measured only that. Per the Docker docs, other setups default to different addresses, and pointing at the wrong one gives the same class of error for a different reason:

Rootless Docker defaults to a per-user socket, typically unix:///run/user/<uid>/docker.sock, not /var/run/docker.sock.
Docker Desktop (macOS/Windows) runs the real engine inside a VM and exposes a proxy socket, typically ~/.docker/run/docker.sock on macOS. Scripts hard-coded to /var/run/docker.sock can fail there even though Desktop is running.
Remote Docker over SSH or TCP (via docker context or DOCKER_HOST=ssh://…) means "the docker daemon running" is a question about a different machine, not yours.

7. How to fix it, in order

Check what address the CLI is actually using. echo $DOCKER_HOST and docker context ls (the one marked * is active). A leftover DOCKER_HOST from another terminal session is a common cause.
If it's the default socket, check the daemon is actually running (sudo systemctl status docker on systemd Linux, or open Docker Desktop).
Check the socket file exists at the address the error names, e.g. ls -la /var/run/docker.sock. Missing entirely usually means the daemon never started or you're on rootless/Desktop with a different path (section 6).
Permission denied instead of cannot-connect (section 5) means add yourself to the docker group, then start a new login shell so the group takes effect.
docker compose erroring the same way as docker ps is normal (section 4) — don't debug them separately.
Remote or SSH hosts: confirm the target host's daemon is up and reachable, not your local one.

For the specific socket-already-exists-but-wrong-owner case, or TCP connect failures in other tools, see ERR_CONNECTION_REFUSED / ECONNREFUSED for how "nothing is listening" looks from other clients.

Frequently asked questions

Why does the error say unix:///var/run/docker.sock even though I didn't type that?

That's the default address the docker CLI tries when you haven't set DOCKER_HOST or a different context. If you see that exact path in the error, you're using default settings and the daemon isn't reachable there.

Is "cannot connect" the same as "permission denied"?

No. In our tests a missing socket or dead port gave "failed to connect to the docker API..." or "Cannot connect to the Docker daemon...". Permission denied (per the Docker docs, section 5) is a different message: the socket exists and the daemon is running, but your user can't read or write it.

Does docker compose give a different error than docker ps?

We measured no difference. docker compose -p <project> ps against the same wrong DOCKER_HOST printed the identical error text as plain docker ps, both for a missing unix socket and for a dead TCP port.

Why did docker version print some output before the error?

docker version and docker info print a Client block first using only local CLI data, then try to reach the daemon for the Server block. In our test the Client block always printed fine; only the Server lookup failed with the connection error.

I'm on macOS with Docker Desktop and get this error. Is it the same fix?

The error shape is the same, but per Docker's docs the default socket path differs (Desktop uses a proxy socket under ~/.docker/run, not /var/run/docker.sock). We didn't measure Desktop; check Desktop is actually running and that nothing hard-codes the Linux socket path.

Written with AI assistance. Measured on 2026-10-02 with Docker Engine 29.8.1 (API 1.56) and Docker Compose v5.5.1 on Linux, by pointing the docker CLI at a deliberately wrong DOCKER_HOST (a missing unix socket, and two TCP ports nothing listens on). The real daemon was never touched. The permission-denied and rootless/Docker Desktop sections are from the Docker docs, not measured, and are labelled as such. PlainHeaders is our extension; curl, Python, Node.js and Chromium are free.