status=213/SECUREBITS в systemd
Код 213/SECUREBITS относится к параметру SecureBits=, который меняет поведение процесса при смене пользователя — например запрещает сброс возможностей. Установка этих битов требует прав, и без них шаг не проходит.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Недостаточно возможностей для смены битов безопасности
Операция требует CAP_SETPCAP. Если возможность исключена из
CapabilityBoundingSet=или служба работает от обычного пользователя, отказ неизбежен. -
Указано неизвестное имя бита
Допустимы keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, noroot-locked. Прочие имена не разбираются.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Показывает шаг SECUREBITS и причину отказа.
journalctl -xeu myapp.service --no-pager -n 20Все параметры возможностей рядом: они влияют друг на друга.
systemctl show myapp.service -p SecureBits -p CapabilityBoundingSet -p AmbientCapabilitiesРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Операция требует CAP_SETPCAP. Если возможность исключена из
CapabilityBoundingSet=или служба работает от обычного пользователя, отказ неизбежен.
- Как проверить
-
Посмотрите параметры вместе.
systemctl show myapp.service -p SecureBits -p CapabilityBoundingSet -p User
- Как исправить
-
Оставьте CAP_SETPCAP в наборе возможностей либо уберите
SecureBits=: без понимания, зачем он нужен, параметр лучше не задавать.
- Почему происходит
- Допустимы keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, noroot-locked. Прочие имена не разбираются.
- Как проверить
-
Проверьте значение.
systemctl show myapp.service -p SecureBits
- Как исправить
- Исправьте имена битов согласно документации или уберите параметр.
Пример вывода
Попытка выставить биты безопасности без CAP_SETPCAP. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
× myapp.service - My application
Active: failed (Result: exit-code) since Mon 2026-09-14 19:52:44 MSK; 1s ago
Process: 17220 ExecStart=/usr/local/bin/myapp (code=exited, status=213/SECUREBITS)
systemd[17220]: myapp.service: Failed at step SECUREBITS spawning /usr/local/bin/myapp: Operation not permittedСвязанные ошибки
- status=218/CAPABILITIES в systemd Код 218/CAPABILITIES: не удалось применить набор возможностей процесса из CapabilityBoundingSet= или AmbientCapabilities=.
- status=227/NO_NEW_PRIVILEGES в systemd Код 227/NO_NEW_PRIVILEGES: не удалось включить запрет получения новых привилегий. Редкий код, обычно из-за окружения.
- bind: Permission denied при привязке к порту Отказ при привязке к порту: обычно порт ниже 1024 у службы от непривилегированного пользователя. Как дать возможность CAP_NET_BIND_SERVICE.
- AppArmor: apparmor="DENIED" в журнале ядра Профиль AppArmor запретил операцию: как прочитать запись, найти профиль и поправить его правильно.
- Caddy не занимает порты 80 и 443 без прав Служба падает при открытии слушателя: нет возможности занимать привилегированные порты.
- Configuration file is marked world-inaccessible Предупреждение о правах на unit-файл: служба работает, но файл недоступен для чтения другим.
- Interactive authentication required при управлении службой systemctl требует аутентификации: обращение от непривилегированного пользователя через polkit. Как разрешить точечно.
- MongoDB: Unable to lock file mongod.lock mongod не запускается: остался файл блокировки после аварийного завершения или каталог принадлежит не тому пользователю.
Источники
-
systemd.exec(5)
213 EXIT_SECUREBITS: не удалось выставить биты безопасности, см. SecureBits=. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на unit с SecureBits=noroot и пустым CapabilityBoundingSet.