服务启动报“Permission denied”时，需按运行身份、路径执行权限、操作类型匹配权限位逐层排查，优先用最小权限修复，避免chmod 777等高危操作。
当服务启动失败并报“Permission denied”，问题往往不在服务本身，而在它访问的文件、目录或资源上缺少必要权限。这类故障不报错在代码里，而藏在系统权限模型中，需按逻辑链条逐层验证。
确认服务运行身份与目标对象的权限匹配关系
服务不是以你当前登录用户身份运行的，而是由 systemd 指定的 User 和 Group（如 User=www-data 或 User=nobody）。先查服务配置：
systemctl show --property=User,Group <服务名>
再用 id -u 和 id -g 确认该用户/组是否存在；接着用 ls -l /path/to/config 或 ls -ld /var/lib/myapp 查看关键路径的权限结构——重点核对第三列（所有者）和第四列（所属组）是否与服务声明的身份一致。若不一致，服务就只能走“others”权限，极易因缺少 r/x/w 而失败。
检查服务依赖路径的可执行（x）权限
服务启动常需读取配置、写入日志、访问数据目录。但很多人忽略：进入目录需要 x 权限，不限于目标文件本身。例如 /opt/myapp/conf/app.conf 启动失败，不能只看 app.conf 的权限，还要依次检查：
-
/opt→/opt/myapp→/opt/myapp/conf
每级都得对服务用户有 x 权限（即dr-xr-xr-x中对应位置是 x）。用以下命令快速验证：namei -l /opt/myapp/conf/app.conf
它会逐层显示各目录的权限和所有者，一眼定位哪一级卡住。
区分操作类型，匹配对应权限位
不同动作依赖不同权限，混淆会导致误判：
- 读配置文件 → 文件需 r，其所在目录需 x
- 写日志或状态文件 → 文件需 w（或目录需 w+x，因创建文件本质是修改目录项）
- 执行二进制或脚本 → 文件本身必须有 x（
chmod u+x），仅靠sh script.sh不可靠，某些环境仍校验底层权限 - 绑定端口（如 80/443）→ 需 CAP_NET_BIND_SERVICE 能力或 root 权限，普通用户即使有文件权限也无法绑定
针对性修复，避开高危操作
找到症结后，优先选择最小改动方案：
- 配置文件属主不对？用
sudo chown www-data:www-data /etc/myapp/config.yml - 日志目录不可写？
sudo chmod 755 /var/log/myapp+sudo chown myapp:myapp /var/log/myapp - 脚本无执行权？
sudo chmod u+x /usr/local/bin/myapp-start.sh - 用户不在所需组里？
sudo usermod -aG myapp-group $USER，然后重启服务或重新登录
坚决避免chmod 777、chown -R root:root或无差别加sudo，这些会破坏最小权限原则，埋下安全风险。
不复杂但容易忽略
