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 the daemon over the socket or host it was told to use. It almost always means the daemon isn't running, the socket path is wrong, or you don't have permission to use it. We reproduced the main causes by deliberately pointing a working Docker install at the wrong place, and compared that with the normal, working connection.

1. What this error means

The docker command you type is only a client. It does no work itself; it sends your request to the Docker daemon (dockerd) over a socket, normally the Unix socket /var/run/docker.sock, or sometimes over TCP. When the client can't open that connection at all, it prints a "cannot connect" style error and exits before it ever reaches the daemon's API.

That is different from an error the daemon itself returns (for example a bad image name). This error happens on the client side, before authentication or any API call is even attempted.

2. Our test setup

We did not stop or break the real daemon. Instead we set the DOCKER_HOST environment variable to point the CLI somewhere wrong, which makes the client fail to connect exactly as it would if the real daemon were down or misconfigured, without touching the working daemon at all.

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

$ DOCKER_HOST=unix:///tmp/nonexistent.sock docker ps
$ DOCKER_HOST=tcp://127.0.0.1:1 docker ps

The first command confirms the real, working socket path on this box. The next two are the broken cases we measured.

3. Results: wrong socket path vs. wrong TCP port

Case	Command	Exact error text	Exit code
Nonexistent Unix socket	`DOCKER_HOST=unix:///tmp/nonexistent.sock docker ps`	"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
Unreachable TCP port (connection refused)	`DOCKER_HOST=tcp://127.0.0.1:1 docker ps`	"Cannot connect to the Docker daemon at tcp://127.0.0.1:1. Is the docker daemon running?"	1
Normal, working socket	`docker ps`	Container table printed normally, no error	0

Both broken cases fail client-side, in well under 20 ms — there is no timeout to wait out, because the connection attempt itself fails immediately (no such file, or connection refused). The exact wording differs by failure type: a missing Unix socket file produces a newer, more detailed "failed to connect to the docker API" message naming the path and the underlying dial error, while a TCP connection refusal produces the older, shorter "Cannot connect to the Docker daemon at <host>. Is the docker daemon running?" phrasing. Both still mean the same thing: the client never reached a daemon.

We saw this same split in docker info and docker version too: the client-side block of output (version, plugins) always prints first, then the daemon connection error replaces the Server section.

$ DOCKER_HOST=unix:///tmp/nonexistent.sock docker version
Client: Docker Engine - Community
 Version:           29.8.1
 ...
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

4. The normal, working case (for contrast)

With DOCKER_HOST unset, the same CLI against the real socket just works, which confirms the broken cases above are genuine connection failures and not a typo in the command:

$ docker version --format '{{.Server.Version}}'
29.8.1
$ docker ps
CONTAINER ID   IMAGE                     COMMAND              STATUS
81a7dcb0bf0b   curlimages/curl:latest    "/watchdog.sh"       Up 4 days
...

Server and client were both Docker 29.8.1, API 1.56, on this box.

5. Common causes

The daemon isn't running. A fresh install, a crashed daemon, or a machine that hasn't finished booting Docker Desktop all look like this from the client's side.
Wrong DOCKER_HOST. A leftover environment variable, a typo'd socket path, or an SSH session that lost a forwarded Docker socket all point the client at nothing. This is exactly what we reproduced above.
Permission denied on the socket. The Unix socket is normally owned by root:docker. A user who isn't in the docker group can see the socket exists but can't open it. Per Docker's docs, this produces a message like "Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock" rather than "no such file" — we did not measure this ourselves, since the account on this box is already a member of the docker group (confirmed with groups), so every command above worked without sudo.
Docker Desktop / VM not started. On macOS and Windows the daemon runs inside a VM; if that VM isn't up, the socket the CLI expects simply isn't there yet.
Rootless or remote context pointed at the wrong place. Switching docker context or using a remote TCP/SSH host that isn't reachable reproduces our TCP case: connection refused, "Is the docker daemon running?".

6. How to fix it

Check the daemon is actually running: systemctl status docker (Linux) or open Docker Desktop and wait for it to report "running".
Check which host the client is using: docker context ls shows the current endpoint; an unexpected one often means a stray DOCKER_HOST in your shell profile. echo $DOCKER_HOST and unset it if it's wrong.
Check the socket file exists and is a socket: ls -la /var/run/docker.sock. "No such file or directory" matches our nonexistent-socket test above and means the daemon never created it.
If it's a permission error, add your user to the docker group (sudo usermod -aG docker $USER, then log out and back in) rather than routinely using sudo docker.
For a remote or TCP host, confirm the port is actually listening and reachable (firewall, SSH tunnel, correct port) — "connection refused" matches our TCP test and means nothing is listening there.

If the daemon connects fine but a specific build or compose run fails afterward, see Docker build failed or docker compose up error. For the exact "Is the docker daemon running?" phrasing on an overlapping search, see Cannot connect to the Docker daemon.

Frequently asked questions

What's the fastest way to check if the problem is the daemon or my command?

Run docker context ls to see the endpoint the CLI is using, then try docker version. The client block (versions, plugins) always prints even when the daemon is unreachable; if the Server block is replaced by an error, the client never reached the daemon at all.

Why does the error wording differ between a missing socket and a dead TCP port?

We measured both on the same Docker 29.8.1 CLI. A missing Unix socket file gives a longer 'failed to connect to the docker API ...: dial unix ...: no such file or directory' message. An unreachable TCP port gives the shorter, older 'Cannot connect to the Docker daemon at <host>. Is the docker daemon running?' phrasing. Both mean the same underlying thing: the connection attempt failed before any API call.

Do I need sudo to run docker commands?

No, not if your user is in the docker group. On this box the account is a member of docker (confirmed with groups) and every docker ps/info/version command above worked without sudo. Routinely using sudo docker instead of fixing group membership just masks the real permission setup.

What does the permission-denied version of this error look like?

Per Docker's documentation (not measured on this box, since our account already has docker group access), it reads along the lines of 'Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock' — distinct from the 'no such file' and 'connection refused' variants we measured.

Does restarting Docker always fix this?

Only if the daemon genuinely isn't running. In our tests the daemon was running the whole time; the failures came from pointing the client at a wrong socket path or a wrong TCP port with DOCKER_HOST. Check docker context ls and your DOCKER_HOST variable before restarting anything.

Written with AI assistance. Measured on 2026-10-02 with Docker 29.8.1 (client and server, API 1.56) on Linux, using the real docker CLI pointed at a deliberately wrong DOCKER_HOST (a nonexistent unix socket, then an unreachable TCP port). The real daemon and its socket were never touched. The docker-group permission-denied message is from Docker's docs, not measured on this box (this account is already in the docker group). PlainHeaders is our extension; the Docker CLI is free and open source.