SystemdDoctor
служба не работает права изоляция

Operation not permitted в журнале службы

Сообщение Operation not permitted (номер 1, EPERM) отличается от отказа в доступе к файлу: тут ядро запрещает саму операцию. У служб под systemd причина почти всегда в параметрах изоляции unit-файла, а не в правах на файлы.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Не хватает возможности процесса

    Операции вроде привязки к порту ниже 1024, изменения приоритета или настройки сети требуют конкретных возможностей. Без них ядро отвечает именно так.

  2. Операцию запрещает фильтр системных вызовов

    При SystemCallErrorNumber=EPERM запрещённый вызов не убивает процесс, а возвращает эту ошибку. Программа сообщает о ней своими словами.

  3. Запрещает модуль безопасности

    SELinux и AppArmor могут запрещать операции при верных правах. Признак — записи в журнале аудита.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Строка с ошибкой и контекст: какая именно операция не прошла.

journalctl -u myapp.service -n 40 --no-pager | grep -iE "not permitted|EPERM"

Все параметры, способные запретить операцию.

systemctl show myapp.service | grep -E "^Capability|^Ambient|^SystemCall|^Restrict"

Сводка по изоляции службы.

sudo systemd-analyze security myapp.service | head -20

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Не хватает возможности процесса
Почему происходит
Операции вроде привязки к порту ниже 1024, изменения приоритета или настройки сети требуют конкретных возможностей. Без них ядро отвечает именно так.
Как проверить
Посмотрите набор возможностей службы. 
systemctl show myapp.service -p CapabilityBoundingSet -p AmbientCapabilities -p User
Как исправить
Выдайте нужную возможность точечно через AmbientCapabilities=, не возвращая службу к правам root.
2. Операцию запрещает фильтр системных вызовов
Почему происходит
При SystemCallErrorNumber=EPERM запрещённый вызов не убивает процесс, а возвращает эту ошибку. Программа сообщает о ней своими словами.
Как проверить
Посмотрите фильтр и записи ядра. 
systemctl show myapp.service -p SystemCallFilter -p SystemCallErrorNumber
journalctl -k -b --no-pager | grep -i seccomp | tail -5
Как исправить
Добавьте нужные вызовы в фильтр или уберите его для разбора, а затем сузьте заново.
3. Запрещает модуль безопасности
Почему происходит
SELinux и AppArmor могут запрещать операции при верных правах. Признак — записи в журнале аудита.
Как проверить
Посмотрите отказы модуля. 
sudo ausearch -m avc -ts recent 2>/dev/null | tail -10
sudo aa-status 2>/dev/null | head -3
Как исправить
Поправьте политику или профиль для нужной операции.

Пример вывода

Служба не может изменить приоритет процесса. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

myapp[4100]: warning: setpriority failed: Operation not permitted
myapp[4100]: fatal: cannot apply scheduling policy: Operation not permitted
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

  • Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
  • status=218/CAPABILITIES в systemd Код 218/CAPABILITIES: не удалось применить набор возможностей процесса из CapabilityBoundingSet= или AmbientCapabilities=.
  • signal=SYS (status=31/SYS) в systemd Процесс службы убит сигналом SYS: фильтр системных вызовов запретил вызов. Как найти запрещённый вызов и исправить SystemCallFilter.
  • status=201/NICE в systemd Код 201/NICE: systemd не смог выставить приоритет процесса из Nice=. Обычно мешает предел LimitNICE или отсутствие прав.
  • Read-only file system в журнале службы Служба не может писать: файловая система только для чтения. Разбор: параметры изоляции unit, монтирование ro, ошибки файловой системы.
  • status=209/STDOUT в systemd Код 209/STDOUT: systemd не смог настроить стандартный вывод службы. Чаще всего виноват путь в StandardOutput=append: или file:.
  • status=210/CHROOT в systemd Код 210/CHROOT: не удалось сменить корневой каталог из RootDirectory= или подключить образ RootImage=.
  • status=229/SELINUX_CONTEXT в systemd Код 229/SELINUX_CONTEXT: не удалось определить или сменить контекст SELinux для процесса службы.

Источники

  • systemd.exec(5)
    Возможности процесса и параметры изоляции.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено попыткой повысить приоритет в службе без CAP_SYS_NICE.     собственная проверка, systemd 255
    сверено 15 сентября 2026