Ошибки и коды · Инструкция
docker.sock permission denied: как исправить без sudo
`permission denied` на `docker.sock` означает проблему доступа клиента к Unix socket Docker daemon.
Короткий ответ
На Linux Docker daemon обычно доступен через root-owned Unix socket. Работать без `sudo` можно через `docker` group, но Docker предупреждает: она даёт root-level privileges; для меньших привилегий рассмотрите Rootless mode.
Почему возникает permission denied на docker.sock
Ошибка означает отсутствие прав клиента на Unix socket daemon, а не проблему конкретного image. Сначала убедитесь, что Docker запущен и проверьте ownership socket. Официальная post-install инструкция предлагает добавить пользователя в docker group и заново войти в session либо использовать обновление group membership. Изменение не всегда начинает действовать в уже открытой shell.
Совет: После добавления в docker group перелогиньтесь: текущая shell может не увидеть изменение.
Как исправить доступ к docker.sock
- Проверьте состояние docker daemon.
- Посмотрите ownership docker.sock и `id -nG`.
- Если принимаете риск, следуйте official docker-group procedure.
- Перелогиньтесь и запустите hello-world.
- Проверьте ownership `~/.docker` при отдельной ошибке.
- Для строгой изоляции изучите Rootless mode.
Предупреждение: Не лечите docker.sock через `chmod 666` — это расширяет доступ к root-capable API.
Нюансы: Rootless Docker и Unix socket
Docker отдельно предупреждает, что membership в docker group предоставляет root-level privileges. Это не мелкая пользовательская группа, поэтому не добавляйте туда недоверенные accounts. Если раньше CLI запускался через sudo, в `~/.docker` могли появиться root-owned files. Тогда socket уже доступен, но другая permission error остаётся в пользовательской конфигурации.
Важно: Если ранее использовали sudo, проверьте ownership файлов в `~/.docker` отдельно.
Пример: группа добавлена, но shell старая
После `usermod -aG docker $USER` текущая shell может не увидеть новую группу до повторного входа — поэтому permission denied сразу после команды ещё возможен.
Безопасная последовательность проверки
Проверьте, что daemon запущен, затем ownership/mode socket и список групп текущего пользователя. Если организация допускает docker group, применяйте официальный post-install procedure и перелогиньтесь, чтобы новое membership вступило в силу. После этого проверяйте обычную команду Docker без sudo.
Почему chmod 666 — плохой «фикс»
Расширение доступа к docker.sock делает daemon доступным пользователям, которым вы, возможно, не хотели давать управление системой. Это хуже, чем явное membership в привилегированной группе, и легко забывается. Для среды с жёсткими требованиями безопасности изучите Rootless mode и его ограничения вместо глобального ослабления socket permissions.
Безопасная проверка прав
- Docker daemon запущен, а ownership и mode `docker.sock` проверены до изменения групп.
- После добавления пользователя в docker group выполнен новый login/session refresh.
- `chmod 666` для socket не используется как постоянное решение.
- Если root-level privileges группы неприемлемы, отдельно оценён Rootless mode.
Что учитывать
Ошибка означает отсутствие прав клиента на Unix socket daemon, а не проблему конкретного image. Сначала убедитесь, что Docker запущен и проверьте ownership socket. Официальная post-install инструкция предлагает добавить пользователя в docker group и заново войти в session либо использовать обновление group membership. Изменение не всегда начинает действовать в уже открытой shell.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Linux post-installation steps for Docker Engine). Пример и формулировки — редакция N1RO на 2026-09-22.