目录权限错误是服务启动失败的高频原因，需逐层检查路径各目录的执行（x）与写入（w）权限、服务真实运行用户与属主/属组匹配、系统组权限（如adm）、SELinux/AppArmor拦截。
目录权限错误是服务启动失败的高频原因——不是程序本身坏了，而是它连“进门”或“动笔”的资格都被系统拒之门外。关键不在报错文字表面，而在路径每一层的属主、权限位、安全上下文是否真正匹配服务运行身份。
逐层检查目录执行与写入权限
目录的 x 权限决定能否进入，w 权限决定能否创建或修改文件。但很多人忽略：路径中任意一层缺失 x，就会卡在“Permission denied”，实际是进不去，不是写不了。
- 用 ls -ld /a /a/b /a/b/c 逐级检查完整路径（如
/var/lib/mysql），确保每级目录对服务用户都有 x 权限 - 目标目录本身还需 w 权限（如
drwxr-x---允许属主读写执行，属组仅能进入和列出） - 若日志路径为
/var/log/myapp/，则/var、/var/log、/var/log/myapp三者都需满足条件
确认服务真实运行用户与组归属
配置文件写的用户 ≠ 实际运行用户。进程 UID 才是系统认的“本人”，必须与其操作路径的属主或属组严格对应。
- 查进程：ps -eo pid,user,comm,args | grep myapp，看实际 UID 和启动命令
- 查 systemd 配置：systemctl show --property=User,Group myapp.service，再用 systemctl status myapp 确认是否生效
- 常见陷阱：MySQL 默认用
mysql用户，但手动初始化时误用 root，导致/var/lib/mysql属主为 root，mysqld 拒绝启动
验证用户是否具备系统级访问组权限
很多日志或数据目录（如 /var/log、/var/lib/mysql）默认只开放给 root 和特定系统组（如 adm、syslog、mysql）。光改目录属主不够，用户还得在对应组里。
- 运行 id 查当前用户所属组，对比目录属组（ls -ld /path 第四列）
- 若缺失，用 sudo usermod -aG adm your_user 加组，加完需重新登录或重启服务才生效
- 临时测试：用 sudo -u your_user touch /var/log/test.log 验证写入能力
排查 SELinux 或 AppArmor 的静默拦截
即使传统权限全对，安全模块也可能在后台拒绝访问，且不提示具体原因，只报泛泛的 “Permission denied”。这是最易被跳过的环节。
- RHEL/CentOS/Fedora：运行 sestatus，若为 Enforcing，先临时切宽容模式 sudo setenforce Permissive 测试是否恢复
- 查拦截记录：sudo ausearch -m avc -ts recent | grep -i denied | grep mysql（或替换为你的服务名）
- Ubuntu/Debian：运行 sudo aa-status，若发现 profile 拦截，可用 sudo aa-logprof 交互式补全策略
- 修复后务必恢复上下文：sudo restorecon -Rv /var/lib/mysql 或对应路径
不复杂但容易忽略
