权限不生效需依次排查inode权限、打开态文件、挂载选项及SELinux/AppArmor：先用stat确认变更是否落地，再用lsof检查进程占用，findmnt查挂载参数，ls -Z和dmesg看安全策略拒绝。

Linux 下 chmod/chown 后权限不生效？先查 stat 和 ls -l 是否真没变

改完权限却还是被拒绝访问，第一反应不是“系统坏了”，而是确认变更是否真的落到了 inode 上。常见情况是命令执行成功但路径写错、符号链接没跟进、或者操作了副本而非原文件。

• ls -l /path/to/file 看输出的权限位和所有者，注意最左边是不是 l（表示软链）——此时你改的是链接本身，不是目标文件
• 用 stat /path/to/file 查 Access、Uid、Gid 字段，它比 ls -l 更权威，能暴露挂载选项或 capability 干扰
• 如果路径含变量或通配符（如 chmod 644 *.conf），先用 echo *.conf 确认实际匹配了哪些文件

进程已打开文件，权限修改对它无效

Linux 不会在文件被打开后动态校验权限——内核只在校验 open() 系统调用时检查一次。所以即使你把一个正在读写的日志文件 chmod 000，只要进程没重启，它照样能写。

• 用 lsof +D /path 或 lsof -p 查哪些进程还持有着该文件句柄
• 服务类进程（如 nginx、redis）通常需要 systemctl reload 或发 SIGHUP 才会重新 open 配置/日志文件
• 调试时可用 strace -e trace=openat,open -p 观察它下次尝试打开时是否失败

挂载选项或文件系统特性屏蔽了权限位

某些场景下，chmod 返回成功，但 stat 显示权限没变，大概率是底层文件系统不支持 POSIX 权限，或挂载时加了压制参数。

• 检查挂载选项：findmnt -t ext4,xfs,btrfs | grep -E "(noexec|nosuid|noacl|mode=)" —— mode= 会强制覆盖文件权限位
• NTFS/FAT32/UDB 分区默认无 uid/gid 概念，Linux 通过挂载参数模拟（如 uid=1000,gid=1000,fmask=0133），此时直接 chmod 无效
• 容器中若用 rootless mode 或 user namespace，chown 某些 UID 可能被映射拦截，/proc/self/uid_map 可查映射范围

SELinux/AppArmor 正在静默拒绝访问

权限位全对，ls -Z 却显示 context 异常，或者 dmesg | grep -i avc 有拒绝日志——说明 MAC（强制访问控制）在起作用，它比传统权限更优先。

• 临时验证：用 setenforce 0（SELinux）或 aa-complain /path/to/bin（AppArmor）关闭策略，看问题是否消失
• 不要长期禁用，应修正策略：ausearch -m avc -ts recent | audit2why 解析拒绝原因，再用 audit2allow 生成新规则
• 常见坑：Web 服务器访问 NFS 共享目录时，SELinux 默认禁止 httpd_can_network_connect 或 use_nfs 未开启

权限不生效从来不是单一原因，而是权限层（POSIX）、打开态（file descriptor）、存储层（mount options）、安全层（SELinux）四者之一或多个叠加的结果。最省时间的做法是按顺序跑一遍 stat、lsof、findmnt、ls -Z && dmesg，别跳步。