服务器权限报错排查

做运维这几年，权限报错几乎天天见。有时候是 Nginx 突然抛 403，有时候是脚本手动能跑、定时任务却报 Permission denied，最烦人的是 SELinux 那种“明明权限都对，就是写不进去”的情况。下面这套排查顺序是我值班时慢慢攒出来的，不需要记太多理论，按步骤走基本能覆盖九成场景。

先抓完整现场，别只看前台报错

看到 Permission denied 先别急着 chmod 777。前台报错往往只是结果，得把完整上下文捞出来。我通常同时开三个窗口查：应用层先看 Nginx、Apache 或业务自身的 error.log，很多路径会直接写在日志里；系统层用 journalctl -xe 或者 tail /var/log/messages 扫一眼，看有没有内核层面的拒绝；如果机器开了 SELinux，立刻去审计日志里找 AVC 记录，ausearch -m avc -ts recent 或者 sealert -a /var/log/audit/audit.log 都能把被拦截的操作列出来。这里有个细节：如果 auditd 没开，临时把它拉起来再复现一次，不然 SELinux 拦了你也看不到证据。

权限链要逐层看，目录执行位最容易漏

定位到具体路径后，按“文件→上级目录→整条路径”的顺序过一遍。stat 命令看权限和归属是基础，但很多人只看目标文件，忘了目录也要有 x 位才能进得去。就算文件是 644，如果上级目录是 700 且归属不对，一样报 Permission denied。

另外一定确认进程到底是以哪个用户在跑。ps aux 配合 grep 看一眼实际 UID，再对比文件 owner，经常发现“我以为它是 nginx 用户，其实是 nobody”。排查整条路径时，推荐用 namei -om /path/to/file，每个节点的权限和归属一目了然，哪里断了瞬间就能定位，比自己一层层 cd + ls 快得多。

SELinux 和特殊权限别忽略

如果常规权限都对，还是报错，八成是 SELinux 在作怪。先用 getenforce 看当前模式，临时切到 Permissive（setenforce 0）验证一下，如果恢复正常，就是 SELinux 策略的问题，再针对性地调整标签或策略即可。