Ошибка: Cannot connect to Docker daemon

Схема проблемы: невозможно подключиться к Docker daemon

Ошибка «Cannot connect to the Docker daemon» — одна из самых частых и одновременно самых простых для исправления проблем при работе с Docker. Docker daemon (dockerd) отвечает за запуск контейнеров, управление образами, сетью и хранилищем. CLI (командная строка Docker) только отправляет запросы демону. Если связь прервана, команды типа docker run или docker ps не выполняются.

Что делает Docker daemon

Docker daemon (dockerd) — это фоновый сервис, который принимает API-запросы от CLI и выполняет работу: создаёт и останавливает контейнеры, строит образы, управляет сетями и томами. На Linux связь между CLI и демоном обычно идёт по Unix-сокету /var/run/docker.sock. На Docker Desktop и в WSL используется именованный pipe или сокет внутри виртуальной машины.

Если CLI не может связаться с демоном, вы увидите сообщение вроде:

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

Иллюстрация: проверка состояния Docker daemon

Обычно причиной являются одна или несколько из следующих ситуаций:

сервис Docker не запущен;
у пользователя нет прав на доступ к Docker-сокету;
активен неправильный Docker context (удалённый демоn/контейнерный хост);
сокет отсутствует или имеет неверные права;
переменные окружения, такие как DOCKER_HOST, указывают на неправильный endpoint;
платформенно-специфичные проблемы (Docker Desktop, WSL, удалённые демоны).

Определение, на каком этапе связи происходит сбой, — ключ к быстрому устранению.

Проверка прав пользователя

На Linux Docker использует Unix-сокет, который обычно принадлежит root и группе docker. Если вы не в группе docker, вы увидите отказ в доступе, если запускаете команды без sudo.

Чтобы проверить права и владельца сокета, выполните:

ls -l /var/run/docker.sock

Вы увидите строку вида srw-rw---- 1 root docker ... /var/run/docker.sock. Это означает, что владелец — root, а доступ имеют root и пользователи из группы docker.

Если вашего пользователя нет в группе docker, добавьте его:

sudo usermod -aG docker $USER

Если группы docker не существует, создайте её:

sudo groupadd docker

После добавления в группу выйдите из сессии и выполните повторный вход (или перезагрузите систему), чтобы изменения вступили в силу.

Проверка, запущен ли сервис Docker

Иногда проблема тривиальна: Docker просто не запущен. Проверьте статус systemd-сервиса:

systemctl status docker

Если вы видите active (running), сервис запущен. Если статус inactive (dead) или failed, демона нет.

Скрин: сервис Docker активен

Чтобы запустить Docker вручную:

sudo systemctl start docker

Чтобы включить автозапуск при загрузке:

sudo systemctl enable docker

Если systemd отсутствует на минимальном сервере, см. раздел ниже про запуск dockerd вручную.

Запуск демона вручную (dockerd)

На минимальных или кастомных системах Docker может не управляться systemd. Попробуйте запустить демон напрямую для диагностики:

sudo dockerd

Анализируйте вывод: dockerd обычно печатает понятные сообщения об ошибках — проблемы с драйвером хранения, конфликт портов, ошибки доступа и т. п. Это даёт указание, что исправлять.

Важно: запуск dockerd в интерактивном терминале блокирует этот терминал; для фонового запуска используйте systemd или сервисный менеджер.

Проверка и исправление Unix-сокета Docker

Сокет /var/run/docker.sock — это транспорт между CLI и демоном. Проверьте наличие:

ls /var/run/docker.sock

Если файл отсутствует, обычно демон не запущен или завершился с ошибкой и не смог создать сокет. Перезапустите Docker, чтобы сокет был создан:

sudo systemctl restart docker

Если сокет есть, но права неверные, исправьте их:

sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock

После этого убедитесь, что ваш пользователь — член группы docker.

Проверка контекстов Docker и переменных окружения

Docker CLI может быть настроен на работу с удалённым демоном. Это делается через Docker contexts и переменные окружения, например DOCKER_HOST.

Проверка переменных окружения

Посмотреть все переменные, связанные с Docker:

env | grep DOCKER

Если вы видите что-то вроде DOCKER_HOST=tcp://localhost:2375, CLI пытается подключиться по TCP к другому демону. Если этот процесс не запущен, связь не состоится. Временно отключить переменную можно так:

unset DOCKER_HOST

Чтобы убрать её навсегда — удалите запись из ваших конфигурационных файлов (~/.bashrc, ~/.zshrc, /etc/environment).

Проверка активного контекста Docker

Контексты показывают, к какому демону обращается CLI. Список и активный контекст можно получить командой:

docker context ls

Звёздочка (*) указывает на активный контекст. Если активный контекст указывает на удалённый хост или на несуществующий ресурс, переключитесь на локальный:

docker context use default

Проблемы, специфичные для платформы

Docker Desktop (Windows/macOS): демон работает внутри лёгкой виртуальной машины. Если VM не стартует, перезапустите Docker Desktop через GUI или перезагрузите систему.
WSL (Windows Subsystem for Linux): демон находится в Linux-окружении. Проверьте, запущены ли дистрибутивы WSL:

wsl --list --running

Перезапуск конкретного дистрибутива или Docker Desktop часто решает проблему.

Удалённый демон (далёкий хост): проверьте сетевой доступ, SSH-туннели и настройки TLS, если они используются.

Пошаговый чек-лист устранения (быстрый порядок действий)

Запустите systemctl status docker и sudo systemctl start docker при необходимости.
Выполните ls -l /var/run/docker.sock — проверьте владельца и группу.
Если не в группе docker — sudo usermod -aG docker $USER и повторный вход.
Проверьте переменные: env | grep DOCKER и выполните unset DOCKER_HOST, если нужно.
Проверьте контекст: docker context ls и docker context use default.
Если systemd отсутствует — попробуйте sudo dockerd и анализируйте вывод.
Просмотрите логи: journalctl -u docker.service --no-pager.

Диагностическая блок-схема

flowchart TD
  A[Запустите docker-команду и получите ошибку подключения] --> B{Сервис запущен?}
  B -- Да --> C{Сокет существует и права корректны?}
  B -- Нет --> D[Запустите: sudo systemctl start docker]
  C -- Нет --> E[Проверьте /var/run/docker.sock, chown/chmod]
  C -- Да --> F{Переменные окружения / контекст}
  F -- Ошибка --> G[unset DOCKER_HOST; docker context use default]
  F -- ОК --> H[Проверьте платформенно-специфические причины: Docker Desktop/WSL/удалённый ли хост]
  E --> H
  D --> C
  G --> H
  H --> I[Если не помогло, смотрите логи и вывод dockerd]

Роли и чек-листы — что делать в вашей роли

Разработчик:
- Убедитесь, что локальный Docker запущен и у вас есть доступ к сокету.
- Не меняйте системные переменные без необходимости.
- Попробуйте docker context use default.
Системный администратор:
- Проверьте systemd-сервис, файлы unit и логи journalctl -u docker.service.
- Проверьте права на сокет, SELinux/AppArmor и файловую систему.
DevOps-инженер:
- Проверьте конфигурации удалённых демонов, TLS-сертификаты и SSH-туннели.
- Автоматизируйте мониторинг статуса демона и алерты при падении.

Полезная шпаргалка с командами

Действие	Команда
Проверить статус	systemctl status docker
Запустить Docker	sudo systemctl start docker
Перезапустить	sudo systemctl restart docker
Посмотреть сокет	ls -l /var/run/docker.sock
Добавить пользователя в группу docker	sudo usermod -aG docker $USER

Когда описанные шаги не сработают (контрпримеры)

Вы используете удалённый приватный демон с TLS, и сертификаты устарели — локальные правки не помогут; нужно обновить TLS/сертификаты и настройки клиента.
Контейнерная платформа изменена (например, Docker заменён на Podman с сокетом, совместимым не полностью) — команды и привилегии могут отличаться.
SELinux или AppArmor блокирует доступ к сокету — потребуется внести исключения в профиль безопасности.

Критерии приёмки

Любая docker-команда (например, docker ps) возвращает список контейнеров без ошибок подключения.
systemctl status docker показывает active (running).
ls -l /var/run/docker.sock показывает группу docker и разрешения не менее 660.
При переключении контекста на default связь с локальным демоном восстанавливается.

Советы для предотвращения ошибок в будущем

Не ставьте DOCKER_HOST глобально в окружение без явной необходимости.
Добавьте проверку статуса Docker в систему мониторинга (например, через systemd-триггеры или SLO-проверки).
Документируйте в команде, какие контексты и конфигурации используются при разработке и в CI.
При использовании Docker Desktop обновляйте версию и следите за доступными патчами.

Часто задаваемые вопросы

Почему я вижу ошибку, хотя Docker был установлен несколько минут назад?

Инсталляция не гарантирует автозапуск демона на всех дистрибутивах. Проверьте systemctl status docker или запустите sudo dockerd вручную, если systemd не используется.

Я добавил пользователя в группу docker, но всё ещё получаю ошибку. Что не так?

После добавления в группу нужен повторный вход в систему (логин/логин) или перезагрузка сессии. Также проверьте, что сокет имеет правильную группу: ls -l /var/run/docker.sock.

Docker Desktop показывает «Docker is starting» долгое время — что делать?

Попробуйте перезапустить Docker Desktop через GUI, перезагрузите систему или обновите Docker Desktop. Проверьте логи приложения Docker Desktop.

Как быстро проверить, куда направлен Docker CLI?

Выполните env | grep DOCKER и docker context ls. Это покажет переменные окружения и активный контекст.

Краткое резюме

Если CLI не может подключиться к Docker daemon, проверьте последовательность: сервис запущен → сокет существует и права корректны → переменные окружения и контекст указывают на нужный демон → платформенно-специфичные проблемы. Большинство случаев решается добавлением пользователя в группу docker, перезапуском сервиса или возвратом контекста к default.

Дополнительные ресурсы: изучите логи демона через journalctl -u docker.service, а в случае Docker Desktop — логи приложения и диагностику в разделе Troubleshoot.