🚨 Docker Error Guide: 'Cannot connect to the Docker daemon' Daemon Connection Failures

Exact Error Message

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

You may also see these realistic variants depending on your context and transport:

ERROR: Cannot connect to the Docker daemon at tcp://192.168.59.10:2376. Is the docker daemon running?

Cannot connect to the Docker daemon at unix:///run/user/1000/docker.sock. Is the docker daemon running?

What It Means

The Docker CLI (docker) is a thin client. Every command — docker ps, docker build, docker run — opens a connection to the Docker daemon (dockerd) over an API endpoint and sends the request there. The default endpoint is the Unix socket /var/run/docker.sock. This error means the client tried to reach that endpoint and got nothing: no process is listening, the socket file does not exist, or the client is pointed at the wrong address entirely.

It is purely a connectivity error between client and daemon. It says nothing about your image, your Dockerfile, or your container — those never get a chance to run because the request cannot be delivered. The cause is almost always one of two things: the daemon is not running, or the client is talking to the wrong place. Knowing which of those two it is decides everything that follows, so the diagnostic work below is mostly about answering that single question before you change anything.

One subtlety worth internalizing: the address in the error message is the address the client tried, not necessarily the address the daemon is listening on. When the two disagree — because of a stale DOCKER_HOST, a remote context, or a rootless socket path — the daemon can be perfectly healthy while every command fails. Read the URL in the error carefully; it is your first clue about where the client is actually pointed.

Common Causes

• dockerd is not running or crashed. The service is stopped, masked, never enabled, or died on startup.
• The daemon failed to start. A syntax error in /etc/docker/daemon.json, an invalid storage driver, or a corrupt state directory makes dockerd exit immediately after launch.
• Wrong DOCKER_HOST. An exported DOCKER_HOST (often a leftover from a Minikube docker-env, a CI runner, or a remote host) points the client at an address with no daemon.
• Active context points elsewhere. docker context use selected a remote or stale context, so the CLI ignores the local socket.
• Rootless vs rootful socket mismatch. Rootless Docker listens on /run/user/<uid>/docker.sock, not /var/run/docker.sock. Switching modes without re-pointing the client breaks the connection.
• Snap or systemd packaging issues. The snap service is stopped, or the systemd unit is masked.

How to Reproduce the Error

This error is reliably reproducible. Stop the daemon and run any client command:

sudo systemctl stop docker docker.socket
docker ps
# Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Or point the client at a dead endpoint without touching the daemon:

DOCKER_HOST=tcp://127.0.0.1:2376 docker info
# Cannot connect to the Docker daemon at tcp://127.0.0.1:2376. Is the docker daemon running?

Diagnostic Commands

Start by confirming whether the daemon is actually up, then check where the client is pointed.

# Is the daemon running, and did it crash on start?
systemctl status docker
journalctl -u docker --no-pager -n 40

# Does the socket exist, and who owns it?
ls -l /var/run/docker.sock

# Where is the CLI pointed? (context + env override)
docker context ls
echo "DOCKER_HOST=$DOCKER_HOST"

# Full client/server view — if server section errors, daemon is unreachable
docker info

A healthy daemon shows active (running):

● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-06-24 09:12:03 UTC; 2h ago

A daemon that died on a bad config looks like this in the journal:

dockerd[4412]: failed to load daemon config: invalid character '}' looking for beginning of object key string
dockerd[4412]: unable to configure the Docker daemon with file /etc/docker/daemon.json
systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: docker.service: Failed with result 'exit-code'.

Step-by-Step Resolution

1. Check the daemon state. Run systemctl status docker. If it is inactive (dead), start and enable it:

   sudo systemctl enable --now docker
   docker ps

2. If it won’t stay running, read the journal. journalctl -u docker -n 40 almost always names the cause. The two most common are a bad daemon.json and a broken storage driver.

3. Validate daemon.json. A single trailing comma or stray brace stops the daemon cold:

   sudo python3 -m json.tool /etc/docker/daemon.json

   Fix the JSON (or move it aside to test: sudo mv /etc/docker/daemon.json /etc/docker/daemon.json.bak), then restart:

   sudo systemctl restart docker

4. Clear a wrong DOCKER_HOST. If the env var points somewhere dead, unset it for the session and persistently:

   unset DOCKER_HOST
   # then remove the line from ~/.bashrc / ~/.zshrc / CI env if present

5. Switch back to the right context. List contexts and select the local one:

   docker context ls
   docker context use default

6. Handle rootless mode. If you run rootless Docker, point the client at the user socket and start the user service:

   systemctl --user start docker
   export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
   docker info

7. Snap installs. If Docker came from snap, manage the snap service instead:

   sudo snap services docker
   sudo snap start docker

How to Prevent the Issue

• Always run sudo systemctl enable --now docker after install so the daemon survives reboots.
• Validate /etc/docker/daemon.json with json.tool (or in CI) before restarting the daemon in production.
• Keep DOCKER_HOST out of your shell profile unless you genuinely target a remote daemon; prefer docker context so the override is explicit and listable.
• Be deliberate about rootless vs rootful — document which mode a host uses so the socket path is never a surprise.
• After changing the storage driver or data root, restart in a maintenance window and watch journalctl -u docker for a clean start.
• In CI runners and ephemeral build hosts, add a readiness gate (a short retry loop on docker info) before the first Docker command so a slow-starting daemon doesn’t fail the pipeline with this exact error.
• When you deliberately use a remote daemon, name the context explicitly (docker context create) and reference it per-command with docker --context <name> ... rather than exporting DOCKER_HOST globally, so a forgotten export never bleeds into unrelated work.

Related Docker Errors

• Docker Error: Got permission denied while trying to connect to the Docker daemon socket
• Docker Error: OCI runtime create failed: runc create failed
• Docker Error: executable file not found in $PATH
• More in the Docker guides.