"Cannot connect to the Docker daemon. Is the docker daemon running?": every cause

1. Is the service running?

sudo systemctl status docker

If it’s inactive, start it, and make it start at boot too:

sudo systemctl enable --now docker
docker ps

A machine that’s just been installed, or rebooted with the service disabled, is the classic case. Docker is also socket-activated on many systems, through docker.socket, so check both:

systemctl status docker.socket

2. It won’t start: read why

failed needs the log:

sudo journalctl -u docker -n 50 --no-pager

Here’s what you may find in it:

To see the errors directly, run it in the foreground after stopping the service:

sudo systemctl stop docker docker.socket
sudo dockerd --debug

Press Ctrl+C when you’re done, then start the service again.

Job for service failed goes through reading a failing service in general.

3. Is the client looking in the wrong place?

The service can be running while the client calls some other address. Look at where it’s pointed:

echo "$DOCKER_HOST"
docker context ls

DOCKER_HOST overrides everything. A leftover in your shell profile or a .env file sends the client to a server that isn’t there:

unset DOCKER_HOST

Contexts do the same thing, more quietly. The current one has a *:

NAME            DESCRIPTION                               DOCKER ENDPOINT
default         Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux * Docker Desktop                            unix:///home/alex/.docker/desktop/docker.sock

With Docker Desktop installed on Linux, desktop-linux looks for the Desktop daemon, even if the Engine you want is running. Switch to the other one:

docker context use default

4. Docker Desktop

On macOS and Windows, the daemon lives inside Docker Desktop, so it has to be open, and finished starting: wait for the whale icon to stop moving. A newer Mac can also show a different path in the message:

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

That still just means it isn’t running. Set Desktop to Start Docker Desktop when you sign in under Settings → General, if you use it every day. On a Mac, you can start it from a terminal:

open -a Docker

5. WSL

There are two setups in Windows Subsystem for Linux, and they fail differently:

With Docker Desktop: open it, then Settings → Resources → WSL Integration, and enable your distribution.

With Docker Engine installed inside WSL: older setups have no systemd, so nothing starts the daemon. Turn systemd on in /etc/wsl.conf:

[boot]
systemd=true

Then, in Windows, restart it with wsl --shutdown. If WSL itself won’t start, see WSL error 0x80370102.

6. Rootless Docker

Rootless Docker runs as your user, with its socket in your runtime folder, so sudo systemctl won’t find it:

systemctl --user status docker
systemctl --user start docker
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/docker.sock

Make it survive logging out with sudo loginctl enable-linger $USER.

7. In a container or CI job

A container doesn’t have a daemon of its own. The options are:

• GitLab CI: add the docker:dind service. The CI/CD Pipeline Generator writes this, including its TLS settings, and on your own runner it needs privileged = true.
• GitHub Actions: the ubuntu-latest runner already has Docker, so you only need to take care when a job runs inside a container:.
• Mount the host’s socket: -v /var/run/docker.sock:/var/run/docker.sock. It works, but it hands that container full control of the host, so use it only for tools you trust.

Often you don’t need a daemon just to build an image. BuildKit and tools such as Kaniko or Buildah can build without one.