权限不生效需依次排查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 <pid></pid>查哪些进程还持有着该文件句柄 - 服务类进程（如 nginx、redis）通常需要
systemctl reload或发SIGHUP才会重新 open 配置/日志文件 - 调试时可用
strace -e trace=openat,open -p <pid></pid>观察它下次尝试打开时是否失败
挂载选项或文件系统特性屏蔽了权限位
某些场景下，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，别跳步。
