User= в systemd: от кого работает служба
Задаёт системного пользователя, от имени которого выполняются процессы службы. Без него служба работает от root, что для большинства служб излишне.
Проверено на тестовой машине: systemd 255, Ubuntu 24.04. Сверено с документацией 15 сентября 2026. Как мы проверяем
Что делает
Смена пользователя происходит до запуска программы, поэтому все последующие действия — переход в рабочий каталог, открытие файлов вывода, доступ к файлам — выполняются уже от него. Это объясняет, почему проверять права надо через sudo -u, а не от root: root видит совсем другую картину.
Пользователя systemd не создаёт (кроме случая DynamicUser=yes). Он должен существовать в системе на момент запуска, иначе служба падает с кодом 217/USER. Для служб принято завести системного пользователя без оболочки и домашнего каталога.
Где ставится. В секции [Service]. Для служб пользователя (systemctl --user) параметр недоступен.
Значения
| Значение | Что происходит |
|---|---|
app | имя существующего пользователя. |
998 | числовой идентификатор — работает, но читается хуже имени. |
%i | подстановка экземпляра в шаблонном unit. |
Пример
Служба от отдельного пользователя с доступом только к своим каталогам.
[Service]
User=app
Group=app
StateDirectory=myapp
ExecStart=/usr/local/bin/myappПараметр StateDirectory= тут не случайно: systemd сам создаст /var/lib/myapp и назначит владельцем пользователя службы.
Типичные ошибки
Пользователя нет в системе — запуск завершается кодом 217/USER до выполнения программы.
Порты ниже 1024 недоступны обычному пользователю: нужна возможность CAP_NET_BIND_SERVICE или сокет-активация.
После добавления параметра к работавшей службе каталоги и файлы остаются принадлежать root: их нужно передать новому пользователю.
Окружение пользователя (.bashrc, .profile) служба не читает: переменные задаются в unit-файле.
Связанные ошибки
- status=217/USER в systemdКод 217/USER означает, что systemd не смог определить или сменить пользователя из User=. Разбор причин: пользователя нет, имя недопустимо, конфликт с DynamicUser.
- Permission denied в журнале службыОтказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- bind: Permission denied при привязке к портуОтказ при привязке к порту: обычно порт ниже 1024 у службы от непривилегированного пользователя. Как дать возможность CAP_NET_BIND_SERVICE.
- status=200/CHDIR в systemdКод 200/CHDIR означает, что systemd не смог перейти в каталог из WorkingDirectory= до запуска программы. Причины и решение.
Рядом стоящие параметры
Где важен на практике
Источники
- systemd.exec(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)