permission denied 的常见原因
permission denied 并不只意味着文件权限位不对。常见原因包括：路径中某一级目录缺少可进入的执行位、文件所在文件系统以只读方式挂载、强制访问控制（如 SELinux）拒绝访问、以及服务以自身运行用户而非登录用户身份判定权限。排查时应沿完整路径逐级确认权限，并区分身份、挂载属性与安全策略三类因素，而不是一味放宽权限位。
基本信息
| 逐级检查 | namei -l 输出路径各层权限 |
|---|---|
| 身份核对 | 服务以运行用户判定，不是登录用户 |
| 挂载属性 | mount 查看是否只读挂载 |
| 安全策略 | getenforce 查当前模式，dmesg 看拒绝记录 |
| 权限修正 | chmod 或 chown，遵循最小权限原则 |
典型使用场景
- 服务启动报权限不足，需要确认以哪个用户身份访问哪些路径
- 手工用 root 测试正常、以服务账号运行却失败，定位身份差异
- 路径中间目录缺执行位导致访问失败，只看目标文件看不出问题
- 存储或系统盘异常后变为只读挂载，写入类操作全部失败
- 安全策略拒绝访问但日志显示权限位正常，需要查看拒绝记录
- 排查 NFS 或共享目录的权限问题，关注映射与挂载参数
逐层检查与修正
逐层检查与修正
namei -l /data/app/log/app.log # 沿路径列出各级权限与属主
ls -ld /data /data/app /data/app/log # 逐层确认目录权限
mount | grep ' /data ' | grep -q ro && echo '存在只读挂载' # 检查只读
getenforce 2>/dev/null # 安全策略当前模式
dmesg -T | grep -i denied | tail # 安全策略拒绝记录
sudo -u appuser test -r /data/app/log/app.log && echo 可读 || echo 不可读 # 以服务身份测试
# 目录需要执行位才能进入并访问其下文件：
# chmod o+x /data # 示例，按最小权限评估后再改
# 只读挂载：mount -o remount,rw /data
# 安全策略：按策略重新打标签（如 restorecon）原因分类与判据
| 原因 | 典型现象 | 验证方式 |
|---|---|---|
| 权限位不足 | 目标文件权限不含所需位 | ls -l 与 sudo -u 实测 |
| 父目录缺执行位 | 目标文件权限正常仍拒 | namei -l 逐级查看 |
| 只读挂载 | 写入类操作一律失败 | mount 查看挂载属性 |
| 安全策略拒绝 | 权限位正常仍被拒 | getenforce 与拒绝日志 |
| 身份不匹配 | root 可以服务账号不行 | 以服务用户身份测试 |
服务进程以它自己的运行用户判定权限，不是以登录用户；核对权限时切换到该身份测试，比用 root 反复试更接近真实情况。
放宽权限到人人可读写不是解法：只读挂载与安全策略拒绝都不会因此消失，而且会引入新的安全问题；先分层定位原因再动手。