权限报错完整流程

线上碰到 Permission denied，第一反应别急着 chmod 777。先搞清楚当前操作身份。通过 whoami 确认当前用户，用 id 查看所属组。如果怀疑是身份问题，用 sudo -i 或 su - target_user 切换后再跑一次，确认是全局报错还是特定账号被拦截。

第一步：基础权限位

ls -l 是排查起点。读操作需要 r，写操作需要 w，执行脚本或进入目录需要 x。目录权限较为特殊：cd 进入靠 x，ls 列表靠 r。缺什么补什么，通常 chmod 755 给目录，chmod 644 给普通文件。遵循最小权限原则，能 755 就别 777，避免配置暴露。

第二步：文件归属对不对

权限位正常仍报错，多半是属主不对。ls -l 第三、四列查看 owner 和 group。例如服务运行在 www-data 下，文件属主却是 root，必然被拒。使用 chown www-data:www-data file 修正。多人协作时建议建立共用组，文件组改为该组并设权限 664；目录可加 setgid（chmod 2770）让新文件自动继承组属性。

第三步：特殊权限与 ACL

除了 rwx，setuid、setgid、sticky bit 也会影响访问。需以文件所有者身份执行时才考虑 u+s，平时慎用。公共目录防误删用 +t。若 rwx 正常仍无法访问，用 getfacl 检查是否有 ACL 覆盖了标准权限。setfacl -m 修正，setfacl -x 清理多余条目。

第四步：SELinux 或 AppArmor 拦截

在 CentOS 或 RHEL 上，权限正确也可能被 SELinux 拦截。ls -Z 查看安全上下文，restorecon -Rv 恢复默认。可用 setenforce 0 切换宽容模式快速验证，若报错消失则用 audit2allow 生成策略模块，生产环境切勿直接关闭 SELinux。Ubuntu 系统需留意 aa-status，检查 AppArmor 是否限制了程序。

第五步：挂载选项限制

通过 mount | grep 挂载点，检查 noexec、nosuid、nodev 选项。当 /tmp 被 noexec 挂载时，脚本无法执行，需更换分区或重新挂载。云服务器若使用 NFS，重点关注 exportfs 中的 root_squash，它会把 root 映射为 nobody，导致权限看似足够实则不足。

第六步：容器与 systemd 限制

容器或 systemd 服务中常隐藏着权限限制。使用 systemctl show 服务名，检查 NoNewPrivileges、CapabilityBoundingSet 是否剥离了关键能力。容器内用 capsh --print 查看当前 capabilities，seccomp 或 cgroup 限制导致的 EPERM 无法通过修改宿主机文件权限解决，必须调整编排配置。

第七步：验证与追踪

修复后切回报错用户重试，echo $? 确认返回 0。建议按此顺序建立排查清单：身份、基础权限、归属、ACL、SELinux、挂载选项、服务限制。若仍受阻，使用 strace -f 跟踪系统调用，区分 EACCES（传统权限不足）和 EPERM（安全模块或 capabilities 拒绝），顺藤摸瓜即可定位问题。