看到 Permission denied（EACCES）或 Operation not permitted（EPERM），先别急着 chmod 777。Linux 权限问题基本能拆成四件事：谁在操作、操作哪个路径、路径上每一级目录能不能穿过去、有没有额外策略（ACL、挂载选项、SELinux/AppArmor、sudoers）在拦。按这个顺序查，多数情况不用重启服务就能定位到是哪一层。
遇到权限不足，先确认三件事：运行进程的实际用户是谁、目标路径每一级目录的执行位是否齐全、文件属主和属组是否匹配。用 namei -l 逐层看一眼，比反复改 chmod 有效。改之前把原权限记下来，改完用目标用户身份复测——root 能读不代表业务能读。目录级放行属于临时缓解，不是最终方案。
Linux权限不足先定位在哪一层
先判断问题出在哪个环节，再动手改。下面四层从上往下看，前面的层没问题再往下走，避免改错地方反复来回。
- 文件自身权限位：
ls -l /path/file看三段 rwx。判断依据是目标进程所属用户/组是否落在“属主/属组/其他”某一段且具备对应位。注意读文件需要 r，写需要 w，进目录和执行脚本需要 x。 - 路径上每一级目录的执行位：这是最容易被忽略的一层。用
namei -l /path/to/file逐级列出，判断依据是每一级目录对目标用户都有x；中间任何一级缺 x，最终文件权限给到 777 也进不去。 - 实际运行身份：
ps -o user,uid,cmd -p <PID>看进程真实用户，systemd 托管的服务用systemctl show -p User -p Group <unit>。判断依据是“你以为的运行用户”和“进程实际用户”是否一致——sudo、su、容器--user、php-fpm 的 pool 配置都会改变这个身份。 - 额外策略层：
findmnt -T /path -o TARGET,FSTYPE,OPTIONS看是否只读挂载或带noexec；getenforce、aa-status看强制访问控制是否在拦；sudo -l看提权策略是否允许这条命令。Read-only file system和Operation not permitted通常落在这一层，而不是文件权限位。
Linux权限不足：先看这四个位置
下面四个位置按“先看客观记录、再看主观猜测”的顺序排，路径都写全，可直接对照执行。
- 日志：Debian/Ubuntu 系看
/var/log/auth.log，RHEL 系看/var/log/secure；服务侧用journalctl -u nginx -n 100 --no-pager，全局报错用journalctl -xe --no-pager；内核和挂载相关用dmesg -T | tail -50；SELinux 拒绝记录在/var/log/audit/audit.log，用ausearch -m avc -ts recent过滤。 - 命令输出：
id（当前用户和组）、namei -l /path/to/file（逐级权限）、stat -c '%A %U:%G %n' /path（权限与属主一行看完）、getfacl -p /path（ACL 是否额外放行或限制）。 - 配置项：
/etc/sudoers及其/etc/sudoers.d/目录（改完用visudo -c校验语法）、systemd 单元的User=与Group=（systemctl cat <unit>可直接看）、/etc/nginx/nginx.conf顶部的user指令、PHP 的/etc/php/<版本>/fpm/pool.d/www.conf里的user/group、/etc/fstab里的挂载选项、/etc/selinux/config的SELINUX=状态。 - 面板字段：文件管理器里的“所有者 / 属组 / 权限（如 644、755）”列，以及站点设置页的“运行用户/PHP 版本”、容器管理页的“运行用户”。不同面板版本的字段名和位置不一样，以你当前界面实际显示的为准，别照抄别人的截图位置。
target=/var/www/html/index.php
id
namei -l "$target"
stat -c '%A %U:%G %n' "$target"
getfacl -p "$target" 2>/dev/null
findmnt -T "$target" -o TARGET,FSTYPE,OPTIONS
getenforce 2>/dev/null || echo "no selinux"这段可以直接粘贴执行，把 target 换成你出问题的路径。输出里先找 ? 或缺 x 的那一级目录，再对照进程用户判断。
Linux权限不足：按可能性从高到低排除
- 文件属主或权限位不对（最常见）。确认：
stat -c '%U:%G %a' /path对比进程用户。
处理：chown -R www-data:www-data /var/www/html，文件一般644、目录755；可写目录（如上传目录）单独给775并把进程用户放进同组。不要对整站跑chmod -R 777。 - 上级目录缺执行位。确认：
namei -l /path逐级看。
处理：给缺失的那一级补chmod o+x或把进程用户加入该目录所属组后chmod g+x，只补必要的那一级。 - 运行身份和预期不一致。确认：
ps -eo user,cmd | grep -E 'nginx|php-fpm|java'。
处理：改服务配置里的User=、nginx 的user、fpm pool 的user，改完systemctl daemon-reload再重启对应服务。容器场景要确认镜像内 UID，必要时用--user指定或调整目录属主到该 UID。 - ACL 或 umask 覆盖了预期。确认：
getfacl -p /path是否有mask限制或拒绝项；umask看新建文件默认权限。
处理：setfacl -m u:www-data:rx /path精确放行，或setfacl -b /path清掉误加的 ACL。 - 挂载选项限制。确认：
findmnt -T /path -o OPTIONS是否含ro、noexec。
处理：noexec需要改/etc/fstab并重新挂载；ro先排查是不是磁盘异常或云盘只读，别直接改挂载掩盖问题。 - SELinux / AppArmor 拦截。确认：
getenforce为 Enforcing 且ausearch -m avc -ts recent有记录。
处理：优先用chcon/semanage fcontext修正文件上下文，或调整 AppArmor profile；不建议长期把 SELinux 设为 Permissive。 - sudoers / polkit 策略拒绝。确认：
sudo -l -U <用户名>，以及日志里带NOT in sudoers的行。
处理：用visudo在/etc/sudoers.d/下新增最小粒度规则，改完visudo -c校验，避免语法错误导致 sudo 整体不可用。
Linux权限不足：改完怎么确认真的解决了
改之前先留一份原状态，改完用目标用户身份复测，而不是用 root 试通就收工。
# 改之前：记录原始权限和 ACL
ls -ld /var/www/html /var/www/html/index.php | tee /tmp/perm-before.txt
getfacl -p /var/www/html/index.php 2>/dev/null | tee -a /tmp/perm-before.txt
# 改之后：用业务身份验证
sudo -u www-data test -x /var/www/html && echo "dir traversable"
sudo -u www-data test -r /var/www/html/index.php && echo "file readable"验证要覆盖两个层面：一是权限判断本身，用上面的 sudo -u 加 test 验证最直接；二是业务行为，重新执行一次之前失败的动作（访问页面、跑一次定时任务、上传一个文件），再 journalctl -f -u <服务名> 跟一段日志，确认没有新的 Permission denied。观察窗口建议至少覆盖一次服务重启和一次正常的读写高峰，比如一次发布或一次定时任务执行之后仍无报错，才算稳定。
回滚要提前准备好。把 /tmp/perm-before.txt 里的原值改回去即可，如果中途动过 ACL，务必一并清掉，否则残留的 ACL 会让“看起来权限已经还原”的目录行为仍然异常：
chown root:root /var/www/html/index.php # 按记录里的原属主属组填写
chmod 644 /var/www/html/index.php # 按记录里的原权限填写
setfacl -b /var/www/html/index.php # 清掉本次新增的 ACL如果是为了“先让业务跑起来”临时加的组权限或 ACL，建议在变更单或注释里标一句何时回收；目录级的大范围放行拖久了没人记得，后续排障会更难判断哪条规则才是真正生效的那条。