Пользователь добавлен в группу, а сервис не получил доступ

Администратор добавил сервисного пользователя в группу reports. Команда id reportbot уже показывает её, но приложение продолжает получать отказ. Файл и каталог имеют подходящие права. Причина может быть во времени: членство в базе учётных записей обновилось, а давно работающий процесс сохранил свой старый список групп.

Сравнить базу и живой процесс

id reportbot
systemctl show report.service -p MainPID -p User -p Group -p SupplementaryGroups
cat /proc/1234/status

Подставьте текущий MainPID и найдите Groups в status. Это числовые дополнительные GID процесса. Например, id показывает 1007(reports), а в Groups работающего процесса есть только 1002. Такое расхождение объясняет отказ лучше, чем повторное chmod файла.

id с именем пользователя получает сведения об учётной записи. Вызов id без имени показывает идентичность текущего процесса команды. Оба полезны, но отвечают на разные вопросы. Список групп процесса хранится в его учётных данных и наследуется потомками; обычное изменение файла группы не переписывает его у всех работающих процессов. Механизм описан в getgroups(2).

Найти место, где формируется контекст

Для systemd проверьте User, Group и SupplementaryGroups в эффективном unit. Настройка службы может явно дополнять или задавать группы. Для интерактивной работы нужна новая сессия входа либо осознанный запуск команды в новом групповом контексте. Перезапуск терминальной вкладки внутри старой родительской сессии не всегда означает полноценное обновление всей цепочки.

Если приложение самостоятельно сбрасывает привилегии или запускает дочерние обработчики под другой учётной записью, проверяйте PID, который действительно открывает файл. Группы главного процесса не доказывают группы всех его детей. В контейнерах и пользовательских пространствах имён добавляется отображение идентификаторов, поэтому эту процедуру проводят в нужном окружении.

Обновить работающую службу

После согласования окна перезапустите службу штатным способом. Перед этим проверьте активные задания и процедуру корректной остановки. Затем получите новый MainPID и повторно прочитайте Groups. Не ограничивайтесь сообщением systemctl о старте: требуется увидеть новый контекст приложения.

Контрольный пример: до изменения PID 1234 имел Groups: 1002; после запуска PID 1450 имеет Groups: 1002 1007. Теперь повторите операцию чтения или записи от приложения. Если отказ остаётся, путь расследования переходит к правам каталогов, ACL, readonly или дополнительным политикам. Обновлённая группа исключает только одну гипотезу.

Зафиксировать зависимость

В инструкции настройки пользователя укажите необходимость нового запуска процессов после изменения групп. Для сервисов удобнее явно документировать, зачем нужна каждая дополнительная группа. Большая общая группа даёт доступ ко всем своим ресурсам, поэтому не добавляйте приложение в административную группу ради одного каталога.

В курсе Linux и Bash для DevOps-инженеров настройка отдельного пользователя связана с запуском сервиса под systemd. Откройте программу, чтобы отработать всю цепочку от записи учётной записи до проверки прав конкретного работающего процесса.

Ещё по теме

• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения
• dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён