Docker permission denied docker.sock: решение // HIP-HOSTING

Docker пишет permission denied на docker.sock? Добавьте пользователя в группу docker, перелогиньтесь и не трогайте chmod 666.

Вы ввели docker ps и получили permission denied while trying to connect to the docker API at unix:///var/run/docker.sock. Docker установлен и работает, просто вашему пользователю не разрешили с ним общаться. Лечится одной командой и повторным входом на сервер. Ниже — почему это срабатывает и что вы при этом отдаёте в плане безопасности.

Коротко. Демон Docker слушает файл-сокет, который открывается только для root и группы docker. Добавьте себя в группу командой sudo usermod -aG docker deploy (вместо deploy подставьте своё имя пользователя) и выйдите из сессии и зайдите снова: уже открытая сессия новую группу не увидит. Не делайте chmod 666 на сокет. Членство в группе docker по сути равно root-доступу, поэтому добавляйте только тех, кому доверяете.

Мы воспроизвели всё на чистом тестовом сервере: Ubuntu 24.04, Docker 29.1.3 из пакета docker.io (apt), обычный пользователь deploy без прав sudo. Команды и выводы в основных шагах сняты в этом прогоне. chmod 666 мы не тестировали, поэтому это только совет.

Что на самом деле означает ошибка

Так выглядит сообщение в актуальной версии Docker:

Команда docker, которую вы набираете, — только клиент. Работу делает демон Docker: фоновая служба, запущенная от root. Клиент общается с ним через сокет — особый файл /var/run/docker.sock, через который программы на одной машине передают друг другу запросы. Сообщение значит: клиент нашёл файл, но при попытке его открыть получил отказ. В старых версиях Docker текст длиннее и сформулирован иначе, причина та же.

Чем это не является: не сетевая проблема и не сломанная установка. Демон жив и отвечает, просто вас к нему не пускают.

Почему пользователя не пускают

Посмотрите, кому принадлежит сокет. Команда показывает файл вместе с правами:

ls -l /var/run/docker.sock

Вы увидите примерно такое:

srw-rw---- 1 root docker ... /var/run/docker.sock

s в начале — это сокет, а не обычный файл.
rw-rw---- — владелец (root) и группа (docker) могут читать и писать, остальным нельзя ничего. В восьмеричной записи это 0660.
root docker — владелец и группа. Пользоваться сокетом могут только они.

Так сделано намеренно: в файле /lib/systemd/system/docker.socket стоят SocketMode=0660 и SocketGroup=docker. Теперь проверьте, кто состоит в группе:

getent group docker

На тестовом сервере вывод был docker:x:112:. Пусто после последнего двоеточия — значит, в группе никого нет. Номер 112 (идентификатор группы) у вас может быть другим. Ваш пользователь не root и в группу не входит, поэтому ядро отказывает.

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

Сначала понадобится учётная запись с правом sudo (или сам root): менять состав групп может только администратор. Дальше одна команда:

sudo usermod -aG docker deploy

usermod правит учётную запись пользователя.
-G docker задаёт дополнительную группу, а -a означает «добавить к существующим». Не убирайте -a: без него usermod заменит все группы пользователя одной docker, и можно потерять доступ к sudo.
deploy — аккаунт, который меняем. Не помните своё имя? Выполните whoami.

При успехе команда молчит. Проверьте через id deploy: в конце списка групп должно появиться 112(docker) (или ваш номер группы).

Ловушка: открытая сессия новую группу не видит

Здесь многие решают, что исправление не сработало. Linux читает группы пользователя один раз, при входе. Терминал или SSH-сессия, открытые до usermod, живут со старым списком. Мы проверили: при сессии deploy, открытой до изменения, id -nG по-прежнему выдавал deploy users, а docker ps получал тот же отказ.

Правильное решение — выйти и зайти заново. Для SSH наберите exit и подключитесь снова. Новый вход видит группу, и docker ps работает.

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

sg docker -c "docker ps"

sg запускает одну команду с включённой группой docker и сразу возвращает вас в обычный режим. Удобно для разовой проверки.

newgrp docker

newgrp открывает подоболочку, где группа уже действует. Выполняйте Docker-команды в ней, а выйти можно командой exit. Исходная сессия не меняется, так что нормальным лечением остаётся новый вход.

Способ	Когда подходит	Подвох
Выйти и войти заново	Обычный случай, всегда	Текущая сессия закроется
`sg docker -c "..."`	Одна команда прямо сейчас	Группу получает только она
`newgrp docker`	Несколько команд, переподключиться нельзя	Работает только внутри подоболочки
`sudo docker ...`	Быстрый разовый запуск, если у аккаунта есть sudo	См. следующий раздел

Как проверить, что всё работает

После нового входа убедитесь, что группа активна и Docker отвечает:

id -nG

docker ps

Первая команда должна показать docker среди ваших групп. Вторая выведет шапку таблицы (CONTAINER ID IMAGE ...) и ваши контейнеры — или ничего под шапкой, если ничего не запущено. Пустая таблица — это успех: ошибки больше нет.

Безопасность: группа docker — это root

Этот пункт важный. Тот, кто может говорить с демоном Docker, способен попросить его запустить контейнер, в который смонтирована любая папка хоста. Демон работает от root, и контейнер тоже. Мы выполнили такую команду от обычного пользователя deploy:

docker run --rm -v /:/host alpine:3 chroot /host id -un

-v /:/host монтирует в контейнер весь диск сервера по пути /host.
chroot /host делает эту папку корнем, и контейнер ведёт себя как настоящая система.
id -un печатает имя текущего пользователя.

Вывод: root. Пользователь без прав sudo стал root на хосте. Поэтому относитесь к группе docker как к группе sudo: добавляйте свою рабочую учётную запись и тех, кому доверили бы пароль root. Общий пользователь «app», служебная учётка веб-сервиса или подрядчик, которого вы знаете неделю, туда не годятся.

Чего делать не нужно

chmod 666 /var/run/docker.sock. Выглядит как короткий путь: теперь сокет открывается для всех. Но заодно уходит единственная защита, и любой аккаунт на сервере, в том числе взломанный процесс сайта, получает root через Docker. Как правило, права ещё и слетают при перезапуске docker.socket — получается дыра и «лечение», которое ломается позже. В лабе мы это не применяли, так что это совет, а не результат проверки.

Вечный sudo перед каждой командой. Работает, если у аккаунта есть права sudo. У пользователя без них в терминале будет неудачный запрос пароля, а в скрипте — sudo: a password is required (второе мы видели на deploy). Но и там, где работает, это не лечит скрипты, задачи cron и Compose-файлы, которые запускает этот пользователь, а файлы, которые контейнеры пишут в примонтированные папки, могут оказаться во владении root. sudo — для быстрого взгляда, а для ежедневной работы лучше группа.

Заходить под root только ради Docker. Ошибка уйдёт, но вместе с ней уйдёт привычка работать под ограниченной учёткой. Root оставьте для администрирования.

FAQ

Почему docker всё равно пишет permission denied после добавления в группу?

Ваша сессия открыта до изменения, а Linux читает группы при входе. Выйдите и зайдите снова или проверьте разово через sg docker -c "docker ps". В нашем тесте открытая сессия отказывала, пока мы не переподключились.

Безопасно ли добавлять пользователя в группу docker?

Только если этому пользователю можно доверить root. Участник группы может запустить контейнер с примонтированным диском хоста и стать root на сервере — мы показали это одной командой docker run. Если такой риск неприемлем, не давайте пользователю доступ к Docker вовсе и запускайте контейнеры сами.

Можно ли решить проблему через chmod на docker.sock?

Технически можно, но не стоит. chmod 666 даёт управление Docker, то есть root, всем аккаунтам на машине. К тому же права, скорее всего, сбросятся при перезапуске сокета. Используйте членство в группе.

Нужно ли перезапускать Docker после usermod?

Нет, демон продолжает работать как раньше. Обновить нужно только сессию пользователя: новая группа появится при следующем входе.

Подходит ли это для snap, rootless Docker и Docker в CI?

Мы их не тестировали и гадать не будем. Статья описывает пакет docker.io из репозитория Ubuntu на Ubuntu 24.04. В rootless-режиме используется другой сокет и другая модель прав.

Коротко

Ошибка значит, что сокет /var/run/docker.sock (root:docker, права 0660) не пустил вашего пользователя: он не состоит в группе docker.
Лечение: sudo usermod -aG docker deploy, затем выйти и войти снова. Ключ -a не убирайте.
Сессия, открытая до изменения, группу не видит. Нужен новый вход; sg и newgrp — временные обходные пути.
Группа docker равна root на хосте. Добавляйте только доверенные аккаунты.
Не делайте chmod 666 на сокет и не строите скрипты на вечном sudo.

Что дальше

Когда Docker работает для вашего пользователя, можно запускать несколько сервисов вместе — Docker Compose на одном VPS. А если образы и логи начнут съедать диск, загляните в разбор как найти, что занимает место, и безопасно очистить.