Cannot connect to the Docker daemon

Fix "Cannot connect to the Docker daemon": run sudo systemctl start docker and sudo usermod -aG docker $USER. Covers contexts, Docker Desktop, WSL and CI.

easy fix·7 min read·6 causes

By Vishvesh Patel·DevOps Engineer·Updated 16 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Check whether the daemon is running at all

inactive or failed means nothing is listening. sudo systemctl start docker fixes it now and sudo systemctl enable docker keeps it after a reboot. On macOS or Windows, start Docker Desktop and wait for the whale to stop animating.

• If it is running, check it is a permissions problem

No output means your user is not in the docker group and cannot read the socket. sudo usermod -aG docker $USER then newgrp docker. Be aware that group is effectively root on the host.

• If both look fine, check where the CLI is pointed

A stale context or a leftover DOCKER_HOST sends the CLI to a machine that is not there. docker context use default and unset DOCKER_HOST bring it back.

If the steps above did not settle it, these are the causes in the order they are usually responsible. Each section explains why it happens and how to confirm it.

The Docker CLI is a client. It does nothing itself. It sends commands to the Docker daemon over a socket. This error means the client could not reach that daemon.

Six realistic causes, and the exact wording of the error narrows it immediately.

That last row is the fastest diagnostic available. If sudo docker ps works and docker ps does not, skip to cause 2.

If it refuses to start, the journal says why:

The usual reasons are a malformed /etc/docker/daemon.json, a trailing comma is enough, a port conflict, or a full disk. Validate the config:

The socket is owned by root:docker, so only root and members of the docker group can use it.

Then log out and back in. Group membership is applied at login, so the change does nothing in your current shell. To test without logging out:

Verify it took effect:

A security note worth stating plainly: membership of the docker group is equivalent to root on that host. Anyone in it can start a privileged container mounting the host filesystem. That is a deliberate trade-off, not an oversight, on a shared or production machine, consider rootless Docker or Podman instead of handing out group membership.

Do not "fix" this with chmod 666 /var/run/docker.sock, which grants every user on the box root-equivalent access permanently.

Docker contexts select which daemon the CLI talks to. A leftover context pointing at a remote host or an old Docker Desktop socket produces this error even with a perfectly healthy local daemon.

The asterisk marks the active one. Switch back:

Also check for a stale environment variable, which overrides the context entirely:

A DOCKER_HOST left over from an old eval $(minikube docker-env) is a common and confusing version of this. Every command silently targets a cluster VM that may no longer exist.

There is no background daemon until Docker Desktop starts. The CLI is installed and on your PATH regardless, so commands fail rather than reporting the application is closed.

Start Docker Desktop and wait for the whale icon to stop animating. Then:

If Desktop starts and immediately stops, the usual causes are insufficient allocated memory, a virtualisation feature disabled in BIOS, or on Windows, WSL 2 not installed. Resetting to factory defaults in Desktop's troubleshoot panel resolves a surprising share of stuck installs.

Docker Desktop runs the daemon in its own WSL distribution, and each distro must be explicitly allowed to reach it.

Settings → Resources → WSL Integration → enable your distro → Apply & Restart.

Without that, docker inside Ubuntu-on-WSL finds the CLI but no reachable socket.

A CI job runs inside a container, which has no Docker daemon of its own. docker build fails here for a structural reason rather than a misconfiguration.

Two supported approaches:

Docker-in-Docker: attach a docker:dind service and point the client at it. Requires the runner to allow privileged mode, which effectively grants host access, so it is a poor choice on shared runners.

Kaniko or BuildKit rootless: builds images from a Dockerfile with no daemon and no privileged mode. This is the better default on shared or multi-tenant runners.

On GitLab CI specifically, a docker:dind service configured while the runner is not in privileged mode produces exactly this error, because the service container silently fails to start.

How do I fix "Cannot connect to the Docker daemon"?

Work out which of two shapes you have. If sudo docker ps succeeds while docker ps fails, it is permissions. Add yourself to the docker group with sudo usermod -aG docker $USER and log out and back in. If both fail, the daemon is not running: sudo systemctl start docker on Linux, or start Docker Desktop on macOS and Windows. If the daemon is definitely up, check docker context ls and $DOCKER_HOST for a stale target pointing somewhere else.

Why does docker work with sudo but not without it?

Because the Docker socket at /var/run/docker.sock is owned by root:docker, so only root and members of the docker group can use it. Adding yourself to that group fixes it, but the change only applies at login. Running the usermod command and continuing in the same shell does nothing, which is why people often think it failed. Log out and back in, or run newgrp docker to pick it up in the current session.

Is adding my user to the docker group safe?

On a personal development machine, it is the normal thing to do. Be aware it is effectively equivalent to granting root on that host: anyone in the docker group can start a privileged container that mounts the host filesystem and escalate from there. On shared or production machines that is a genuine concern, and rootless Docker or Podman are better options. Never work around the permission error with chmod 666 on the socket, which grants the same power to every user permanently.

Why does Docker fail in my CI pipeline with this error?

Because CI jobs run inside a container, which has no Docker daemon of its own. This is structural rather than a misconfiguration. Either attach a Docker-in-Docker service and point the client at it, which requires the runner to permit privileged mode, or use Kaniko or rootless BuildKit, which build images from a Dockerfile without needing a daemon at all. Kaniko is the safer default on shared runners, since privileged mode there effectively grants host access to any job.

What is a Docker context and how can it cause this?

A context tells the CLI which daemon to talk to: a local socket, a remote host over SSH, or Docker Desktop's own socket. If the active context points somewhere unreachable, every command fails with this error even though a healthy daemon is running locally. Run docker context ls to see which is active, marked with an asterisk, and docker context use default to switch back. Also check $DOCKER_HOST, which overrides the context and is commonly left behind by eval $(minikube docker-env).

Docker Desktop is running but I still get this error on Windows. Why?

Almost certainly WSL integration. Docker Desktop runs the daemon inside its own WSL distribution, and each distro you use must be explicitly permitted to reach it. Settings, Resources, WSL Integration, enable your distro, then Apply and Restart. Without that, the docker command inside Ubuntu-on-WSL finds the CLI on the PATH but no reachable socket, producing this error despite Desktop appearing to run normally.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.