#Что означает проблема и кому подходит инструкция
После смены пользователя службы Ubuntu старый UNIX-сокет может остаться во владении прежней учётной записи либо его каталог принадлежит root. При этом процесс запускается, но клиенты получают Permission denied или Connection refused. Безопасность прав сокетов важнее быстрого запуска через chmod 777.
#Возможные причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Сокет остался от прошлого процессаФайл сокета или его каталог создан старой учётной записью. | stat показывает прежнего владельца. | Определить службу-создателя и штатный способ перевыпуска. |
| Клиент не входит в нужную группуСокет создан с правами 0660, но клиент не состоит в группе. | id и stat отличаются. | Настроить узкую группу доступа после оценки. |
| Сокет создаёт systemd.socketПрава и владелец задаются SocketUser, SocketGroup, SocketMode, а не только service User. | systemctl list-sockets показывает нужный адрес. | Исправить настройку собственного socket-unit. |
#Диагностика и пошаговое устранение
- 1. Уточните путь сокета и сообщение ошибкиОткройте Терминал Ubuntu. Посмотрите журнал приложения-клиента и службы, найдите абсолютный путь к сокету.
Permission deniedозначает отказ доступа,Connection refusedчасто означает, что никто не слушает или процесс завершён. Не стирайте файл сокета, пока не проверили, кто его использует. - ss может не показывать владельца процессов без административных правLinux · Терминал (Bash)Командаss может не показывать владельца процессов без административных прав.
systemctl list-sockets --allss -xlpn
- 2. Проверьте владельца файла и каталоговПодставьте реальный путь к сокету вместо /run/app/app.sock. Команды
statиnamei -lпокажут владельца, группу и доступность всех родителей. Для подключения к сокету нужен доступ к самому сокету и возможность пройти по каталогам.Linux · Терминал (Bash)КомандаПуть демонстрационный, ничего не удаляйте.stat /run/app/app.socknamei -l /run/app/app.sock
- 3. Определите, кто создаёт сокетПроверьте существование ИМЯ.socket и ИМЯ.service через
systemctl status/cat. Socket-activated служба получает сокет от systemd, тогда изменениеUser=у сервиса не обязано менять владельца. Если сокет создаёт само приложение, ищите его umask и конфигурацию пути.Linux · Терминал (Bash)КомандаЕсли .socket не существует, изучите настройки самого приложения.systemctl cat ИМЯ.socketsystemctl cat ИМЯ.servicesystemctl list-sockets --all
- 4. Сверьте пользователей и группыПосмотрите
id ИМЯ_КЛИЕНТАиgetent group НУЖНАЯ_ГРУППА— это покажет права клиентского процесса. На службе подDynamicUser=постоянные UID не подходят для закрепления на диске. Не добавляйте всех пользователей в privileged-группы docker, adm и root ради одного сокета. - Подставьте действительные имена; имя клиента может означать системную службуLinux · Терминал (Bash)КомандаПодставьте действительные имена; имя клиента может означать системную службу.
id ИМЯ_КЛИЕНТАgetent group НУЖНАЯ_ГРУППА
- 5. Исправьте права через создателя сокетаДля собственного socket-unit используйте соответствующие SocketUser/SocketGroup/SocketMode в drop-in после резервной копии. Для сокета приложения настраивайте его штатную директорию выполнения,
RuntimeDirectory, и umask. После перезапуска сокет обычно создаётся заново с нужными правами, поэтому ручной chmod на одном файле временный. - Дополнительная команда по темеLinux · Терминал (Bash)КомандаНе даётся универсальная команда chmod/chown из-за риска открыть локальный канал всем пользователям.
systemctl cat ИМЯ.socket
- 6. Проверьте клиента после контролируемого перезапускаПосле согласованного изменения конфигурации и перезапуска сервиса/сокета повторите
statи тест подключения из-под клиента. Не перезапускайте системные сокеты на рабочем сервере без планового окна: соединения могут разорваться. Если ошибка сохранилась, проверяйте фактическую группу процесса и SELinux/AppArmor отдельно.Linux · Терминал (Bash)КомандаОжидаются правильные владелец/группа/режим и успешный запрос клиентского приложения.stat /run/app/app.sockss -xlpn
#Как убедиться, что неисправность устранена
Решение подтверждено после нового создания сокета и успешного подключения только тех пользователей, которым оно разрешено. Универсальный режим 0777 здесь неприемлем.
#Если результат не получен
Не повторяйте опасные действия наугад. Сохраните точную формулировку ошибки, вывод диагностики без секретов, версию Ubuntu и данные о затронутом компоненте. Верните лишь собственные изменения из резервной копии; если затронута загрузка, диски или рабочий сервер, воспользуйтесь консолью восстановления либо помощью администратора.