Fix Docker 'Cannot connect to the Docker daemon' Error

Understanding the "Cannot connect to the Docker daemon" Error

This error message appears when the Docker client (the docker CLI) attempts to communicate with the Docker daemon (dockerd) but fails to establish a connection. The daemon is responsible for building, running, and managing containers. Without it, every docker command returns something like:

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

The error can occur on any operating system and in any environment — local development machines, CI/CD pipelines, remote servers, and inside Docker-in-Docker setups. It essentially means the client cannot reach the background service that does the real work.

Why This Error Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

A functioning Docker daemon is the backbone of all container workflows. When this connection breaks:

Development stops: You can’t build, run, or inspect containers.
CI/CD pipelines fail: Automated builds, tests, and deployments grind to a halt.
Debugging becomes impossible: Commands like docker logs and docker exec are unusable.
Orchestration tools break: Tools that rely on the Docker socket (e.g., docker-compose, Portainer, Kubernetes CRI shims) lose their control plane.

Quickly diagnosing and resolving this connection issue is therefore an essential skill for any developer working with containers.

Common Root Causes

Before applying a fix, it helps to understand the most frequent reasons for the disconnection:

Daemon not running – The service was never started, stopped manually, or crashed.
Permissions – The user running the Docker command lacks access to the daemon’s socket (usually /var/run/docker.sock).
Docker Desktop not launched – On macOS or Windows, the GUI application must be running to provide the daemon and socket.
Wrong Docker context – Docker supports multiple endpoints via contexts; the active context may point to a remote or unavailable daemon.
Environment variables – DOCKER_HOST or DOCKER_SOCKET might be set to an invalid location or a stale remote node.
Systemd socket configuration – On Linux, socket activation may be misconfigured, leaving the socket file present but the daemon inactive.
Rootless mode misconfiguration – When using rootless Docker, the socket location moves to the user’s runtime directory, but the client may still look at the default path.

Step-by-Step Fixes for Linux Environments

1. Verify the daemon status and start it

On distributions that use systemd (Ubuntu, Debian, CentOS, Fedora, etc.), check the Docker service:

sudo systemctl status docker

If it’s inactive or stopped, start it:

sudo systemctl start docker

To make sure it starts automatically after a reboot:

sudo systemctl enable docker

After starting, test with:

docker run hello-world

2. Fix socket permissions (adding user to the docker group)

By default, the Docker socket /var/run/docker.sock is owned by root and the docker group. Only users in that group can interact with the daemon without sudo. If you see a permission error when running as a normal user, add yourself to the docker group:

sudo usermod -aG docker $USER

Then apply the new group membership. You can either log out and log back in, or use the following command to refresh group membership in the current shell (requires newgrp):

newgrp docker

Alternatively, restart the session completely. Verify group membership:

groups

Now try a command like docker info – it should succeed without sudo.

3. Check the socket file itself

Ensure the socket file exists and has the correct permissions:

ls -la /var/run/docker.sock

Typical healthy output:

srw-rw---- 1 root docker 0 May 10 08:12 /var/run/docker.sock

If the file is missing entirely, the daemon hasn’t started or uses a different socket path (e.g., rootless mode). If the permissions are incorrect, the daemon may need to be restarted after fixing the group settings.

4. Rootless Docker socket location

When running Docker in rootless mode, the socket resides under the user’s home directory, typically:

/run/user/$(id -u)/docker.sock

The client needs to know this path. Check the DOCKER_HOST environment variable or set it explicitly:

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

You can persist this by adding it to your shell’s profile (~/.bashrc, ~/.zshrc). Also ensure the rootless daemon is actually running:

systemctl --user status docker

Start it if needed:

systemctl --user start docker

Step-by-Step Fixes for macOS and Windows

1. Ensure Docker Desktop is running

On macOS and Windows, the Docker daemon is bundled inside Docker Desktop. The CLI relies on a socket that Docker Desktop provides. If you see the error:

macOS: Look for the Docker whale icon in the menu bar. If it’s absent, launch Docker Desktop from the Applications folder.
Windows: Check the system tray. If Docker Desktop isn’t running, start it from the Start menu. On first launch it may require WSL2 or Hyper-V configuration – follow the setup wizard.

Once Docker Desktop is running and the status shows “Engine running”, the default socket path (unix:///var/run/docker.sock on macOS inside the VM, or //./pipe/docker_engine on Windows) becomes available automatically.

2. Switch to the default Docker context

Docker Desktop creates a context named default. If you’ve experimented with remote contexts (e.g., staging, production), you might be pointing to an unreachable daemon. List available contexts:

docker context ls

Switch back to the default (local) context:

docker context use default

3. Check environment variables

On both platforms, the DOCKER_HOST variable can override the default connection. Unset it to fall back to the local socket:

unset DOCKER_HOST

Remove any related lines from ~/.bashrc or ~/.zshrc if they were set for a remote daemon.

Fixes for Remote Docker Contexts and CI/CD

1. Validate remote daemon accessibility

When connecting to a remote Docker engine over TCP (e.g., tcp://192.168.1.10:2375), ensure the remote host is reachable and the daemon listens on the correct port:

nc -zv 192.168.1.10 2375

On the remote host, verify the daemon configuration (usually /etc/docker/daemon.json or the startup command) includes the hosts entry:

"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]

Restart the remote daemon after any configuration change.

2. Docker contexts and secure connections

If you use a Docker context with TLS, make sure the certificates are valid and the environment variables (DOCKER_TLS_VERIFY, DOCKER_CERT_PATH) are correct. Inspect the context:

docker context inspect myremote

If the endpoint is wrong, update it or create a new context:

docker context create myremote \
  --docker "host=tcp://10.0.0.5:2376,ca=/path/to/ca.pem,cert=/path/to/cert.pem,key=/path/to/key.pem"

Then switch:

docker context use myremote

3. Docker-in-Docker (dind) scenarios

When running Docker inside a container (e.g., for CI), the daemon might be started as a separate container or via a sidecar. The client inside the container needs to point to the correct socket. Often the socket is mounted as a volume:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

If you are inside a container that needs its own daemon (true dind), start the daemon and ensure the client uses the same socket path. Typically:

dockerd &   # start the daemon in the background
docker info  # test connection

Make sure the socket file appears inside the container. For Alpine-based dind, the daemon often uses /var/run/docker.sock inside the container.

Best Practices to Prevent the Error

Always add your user to the docker group on Linux – this avoids permission-related failures and the need to run every command with sudo.
Enable the Docker service to start on boot (systemctl enable docker) so the daemon is available immediately after reboot.
Keep Docker Desktop’s autostart enabled on macOS and Windows – this launches the daemon when you log in.
Use the default context for local work; create separate named contexts for remote endpoints and switch explicitly. Avoid leaving DOCKER_HOST set in your shell profile unless you always work with a remote daemon.
Monitor daemon health in CI/CD pipelines by adding a step that runs docker info before the main build logic, catching the error early.
When using rootless mode, document the socket path for your team and set DOCKER_HOST accordingly in shared scripts.
Regularly update Docker – newer versions contain bug fixes that can prevent daemon crashes and socket miscommunication.

Conclusion

The “Cannot connect to the Docker daemon” error is a gatekeeper issue that every Docker user encounters sooner or later. By systematically checking whether the daemon is running, whether the user has permission to access its socket, and whether the client is pointing to the correct endpoint, you can resolve it in minutes. Applying the best practices above will drastically reduce its occurrence and keep your container workflows smooth and predictable.