Guides

Fix "Cannot connect to the Docker daemon. Is the docker daemon running?"

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 16 October 2026 · Last updated: 17 October 2026

"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?" means the docker command could not reach the Docker service (dockerd). On Linux and EC2, run sudo systemctl enable --now docker. If it does not start, sudo journalctl -u docker shows why, which is usually a broken /etc/docker/daemon.json or a full disk. On Windows and Mac, start Docker Desktop and wait for "Engine running".

sudo systemctl status docker            # is it active (running)?
sudo systemctl enable --now docker      # start now + start at boot
sudo journalctl -u docker -n 50 --no-pager   # why it failed
docker run --rm hello-world             # test

A live example first

A student restarts an Amazon Linux 2023 EC2 instance after a lab and runs:

docker ps

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

Check the service:

sudo systemctl status docker

○ docker.service - Docker Application Container Engine
     Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; preset: disabled)
     Active: inactive (dead)

Two words matter here: inactive (it is not running now) and disabled (it will not start at boot). The student had run sudo systemctl start docker once, but never enable. After the reboot it was gone. The fix:

sudo systemctl enable --now docker
docker ps

CONTAINER ID   IMAGE   COMMAND   CREATED   STATUS   PORTS   NAMES

An empty table, with no error, means the daemon answered.

Why does Docker say the daemon is not running?

Docker has two parts. The docker command you type is only a client. The real work is done by the daemon, dockerd, a background service. They talk through the socket file /var/run/docker.sock. If dockerd is stopped, crashed or never installed, the client knocks on the socket and nobody answers.

This is different from permission denied while trying to connect to the Docker daemon socket. In that case the daemon is running, but your user is not allowed to use the socket.

How do I fix it on Linux step by step?

1. Run sudo systemctl status docker.
2. If it says inactive or disabled, run sudo systemctl enable --now docker.
3. If it says failed, run sudo journalctl -u docker -n 50 --no-pager.
4. Read the last error line and match it in the table below.
5. Fix the cause and run sudo systemctl restart docker.
6. Run docker run --rm hello-world to prove it works.

Reading journalctl: the four usual causes

The daemon.json trap

Many guides tell you to add a registry mirror or log options:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
}

The comma after the last item makes it invalid JSON. Docker will refuse to start. Check before you restart:

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

If it prints the file back, it is valid. If it prints Expecting property name, fix the line it names.

Fix it on Windows (Docker Desktop + WSL 2)

On Windows the error looks like this:

error during connect: ... open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified.

1. Start Docker Desktop from the Start menu.
2. Wait until the bottom-left corner says Engine running.
3. If it stays on "Starting", open PowerShell as admin.
4. Run wsl --update.
5. Run wsl --shutdown.
6. Start Docker Desktop again.
7. If it still fails, check that virtualisation is turned on in the BIOS (Task Manager → Performance → CPU → Virtualization: Enabled).

Fix it on macOS

1. Open Docker Desktop from Applications.
2. Wait for the whale icon in the menu bar to stop animating.
3. If you use Colima or Rancher Desktop instead, run colima start.
4. Run docker context ls and make sure the active context (with *) is the one that is running.

The docker context and DOCKER_HOST trap

If you once connected to a remote server, your client may still point there:

docker context ls
echo $DOCKER_HOST

Switch back with docker context use default and unset DOCKER_HOST.

Real example: Docker vs containerd in Kubernetes

Kubernetes removed "dockershim" in version 1.24 (May 2022). Since then, Amazon EKS, GKE and AKS nodes run containers with containerd, not the Docker daemon. So on a modern EKS node, docker ps may say "Cannot connect to the Docker daemon" even though every pod is running fine. That is expected. On those nodes use crictl ps or kubectl get pods. Your images built with Docker still run, because they follow the OCI image standard.

Mistakes students make

1. Running start but not enable. It works until the next reboot.
2. Running chmod 666 /var/run/docker.sock. That does not start a stopped daemon, and it lets every user on the machine control Docker (which is the same as root). Never do it.
3. Editing daemon.json and restarting without checking. Always run json.tool first.
4. Expecting Docker on Kubernetes nodes. Use crictl there.

Summary table