Skip to content

Revision 1 — the current text. The evidence on this page is this revision’s own — it has not been carried forward from, or to, any other revision.

Fixing 'Cannot connect to the Docker daemon'

Checks whether the daemon is actually running, then whether DOCKER_HOST or the active Docker context is pointing somewhere unexpected. It also flags the socket-permission lookalike ('Got permission denied' rather than 'Cannot connect') as a distinct message with a distinct fix, so it isn't mistaken for a dead daemon.

Docker
Unverifiedno reproductions yetWhy this confidence?
Revision 1published by DevYou curation

Symptoms

The diagnostic path

8 steps, exactly as this revision published them.

  1. Step 1 · Startdocker: Cannot connect to the Docker daemon

    This message means the CLI couldn't reach a daemon at all via the socket it tried — it's distinct from a 'permission denied' error on the same socket, which means it reached the socket but was refused access.

    What happens next

    • passed → step 2, Is the daemon process actually running?

  2. Step 2 · TestIs the daemon process actually running?

    Check the daemon's own service status before assuming it's a client-side configuration problem.

    Read-onlysh
    systemctl status docker

    Expected result

    docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled)
     Active: inactive (dead) since Thu 2026-08-20 09:12:03 UTC; 4min ago

    What happens next

    • passed → step 3, Is DOCKER_HOST pointing somewhere unexpected?
    • failed → step 4, Fix: start the daemon
    • unknown → step 4, Fix: start the daemon

  3. Step 3 · TestIs DOCKER_HOST pointing somewhere unexpected?

    The daemon is running, so check whether the CLI is being told to talk to a different (possibly stale or remote) endpoint instead of the local socket.

    Read-onlysh
    echo $DOCKER_HOST

    Expected result

    tcp://old-build-host:2375

    What happens next

    • passed → step 5, Fix: unset DOCKER_HOST
    • failed → step 6, Is the active Docker context pointing at a stale endpoint?
    • unknown → step 6, Is the active Docker context pointing at a stale endpoint?

  4. Step 4 · FixFix: start the daemon

    The daemon isn't running. If it was crash-looping rather than simply stopped, check journalctl -u docker for why before assuming this alone fixes it.

    Changes statesh

    Changes system or service state. Review before running.

    Starts the Docker daemon service on this machine.

    sudo systemctl start docker

  5. Step 5 · FixFix: unset DOCKER_HOST

    A stale or incorrect DOCKER_HOST is overriding the default local socket.

    Changes statesh

    Changes system or service state. Review before running.

    Removes the DOCKER_HOST override for the current shell session only; future docker invocations in this terminal use the default local socket instead.

    unset DOCKER_HOST

  6. Step 6 · TestIs the active Docker context pointing at a stale endpoint?

    DOCKER_HOST isn't the issue — check docker context ls for the currently selected context and where it points, which can be left over from a remote/rootless setup or a Docker Desktop reinstall.

    Read-onlysh
    docker context ls

    Expected result

    NAME       DESCRIPTION       DOCKER ENDPOINT
default    Current context   unix:///var/run/docker.sock
remote-vm *                  ssh://build@old-vm

    What happens next

    • passed → step 7, Fix: switch back to the default context
    • failed → step 8, Socket and context are both fine — check permissions instead
    • unknown → step 8, Socket and context are both fine — check permissions instead

  7. Step 7 · FixFix: switch back to the default context

    The active context is pointed at an endpoint that no longer exists or isn't reachable.

    Changes statesh

    Changes system or service state. Review before running.

    Switches the Docker CLI's active context back to 'default' for this user; it does not affect the daemon itself, only which endpoint the CLI talks to.

    docker context use default

  8. Step 8 · EndSocket and context are both fine — check permissions instead

    If the error text actually reads 'permission denied' rather than 'cannot connect' — a distinct message on the same socket — the user running docker isn't in the docker group (sudo usermod -aG docker $USER, then log out and back in) rather than the daemon being unreachable. If it's truly the same 'cannot connect' wording, try sudo docker version: if that works, it confirms a permissions problem rather than a dead daemon, despite the wording.

Sources

Why this confidence?

What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.

This counts only what was recorded against revision 1 itself. Nothing reported against another revision is included here — see the revision history for why.