通常因服务需特权操作但 systemd 未授予权限，应先查 journalctl 日志定位失败系统调用，再依需配置 CapabilityBoundingSet 与 AmbientCapabilities、调整 User/Group 或启用 DynamicUser。
systemd 服务启动报 Operation not permitted 怎么定位
这通常不是 selinux 或 apparmor 的锅，而是服务进程尝试执行需要特权的操作（比如绑定低端口、设置 cap_net_bind_service、切换用户），但 systemd 没给它对应权限。先看日志：journalctl -u your-service.service -n 50 --no-pager，重点找 operation not permitted 或 permission denied 后紧跟的系统调用（如 bind(2)、setuid(2)）。
常见诱因：
-
CapabilityBoundingSet缺失关键 capability（如CAP_NET_BIND_SERVICE） -
User=和Group=配置后，进程降权太早，来不及绑定端口 - 服务二进制本身没设
setcap，又没在 unit 文件里声明 capability
绑定 80/443 端口失败的典型修复路径
Linux 默认禁止非 root 进程绑定 1024 以下端口。有三种合法解法，按推荐顺序：
- 用
CapabilityBoundingSet=CAP_NET_BIND_SERVICE+AmbientCapabilities=CAP_NET_BIND_SERVICE，再配User=www-data—— 这是最干净的做法，无需改二进制或开 root - 改用高端口（如 8080），前端用反向代理转发 —— 开发/测试环境最快捷
- 给二进制加 capability：
sudo setcap 'cap_net_bind_service+ep' /usr/local/bin/your-app，但要注意：该 capability 在 fork 后不会自动继承到子进程，且 systemd 会清空 ambient caps，所以仍需在 unit 中显式配置AmbientCapabilities
别直接设 RootDirectory= 或 ProtectSystem= 后还硬要 bind 80 —— 权限模型已变，不补 capability 就必然失败。
服务以非 root 用户启动却提示 Failed at step USER spawning
这不是权限不足，是 systemd 启动时无法切换到目标用户，根本原因是目标用户的 home 目录不存在或权限不对，或者 /etc/passwd 里该用户 shell 被设为 /bin/false 或 /usr/sbin/nologin（systemd 会拒绝启动）。
- 检查用户是否存在：
id www-data - 确认 home 目录可读：
ls -ld /var/www（若User=www-data且未指定DynamicUser=yes） - 确保
Shell:字段是有效登录 shell（如/bin/bash或/bin/sh），哪怕只是临时改成它来验证 - 更安全的替代方案是启用
DynamicUser=yes，让 systemd 在启动时动态创建用户，避免依赖系统用户配置
为什么加了 CapabilityBoundingSet 还报错
因为 capability 是分层的：CapabilityBoundingSet 只控制「上限」，不自动赋予；真正生效还得靠 AmbientCapabilities（让 capability 在 execve 后保留）或 ExecStartPre 里用 setcap 临时提权（不推荐）。
- 必须同时设置：
CapabilityBoundingSet=CAP_NET_BIND_SERVICE+AmbientCapabilities=CAP_NET_BIND_SERVICE -
SecureBits=keep-caps已被 systemd 弃用，不要写 - 如果服务内部调用了
setuid()，capability 会被丢弃 —— 此时只能用DynamicUser=yes+SupplementaryGroups=配合，或彻底重构服务不降权
最常被忽略的一点：AmbientCapabilities 在旧版 systemd（systemd --version。低于这个版本，只能退回到 setcap + root 启动，或升级系统。
