权限不生效需依次排查inode权限、打开态文件、挂载选项及SELinux/AppArmor：先用stat确认变更是否落地，再用lsof检查进程占用，findmnt查挂载参数，ls -Z和dmesg看安全策略拒绝。
Linux 下 chmod/chown 后权限不生效？先查
和
是否真没变
改完权限却还是被拒绝访问，第一反应不是“系统坏了”，而是确认变更是否真的落到了 inode 上。常见情况是命令执行成功但路径写错、符号链接没跟进、或者操作了副本而非原文件。
看输出的权限位和所有者，注意最左边是不是
（表示软链）——此时你改的是链接本身，不是目标文件
用
查
、
、
字段，它比
更权威，能暴露挂载选项或 capability 干扰
如果路径含变量或通配符（如
），先用
确认实际匹配了哪些文件
进程已打开文件，权限修改对它无效
Linux 不会在文件被打开后动态校验权限——内核只在校验
系统调用时检查一次。所以即使你把一个正在读写的日志文件
，只要进程没重启，它照样能写。
用
或
查哪些进程还持有着该文件句柄
服务类进程（如 nginx、redis）通常需要
或发
才会重新 open 配置/日志文件
调试时可用
观察它下次尝试打开时是否失败
挂载选项或文件系统特性屏蔽了权限位
某些场景下，
返回成功，但
显示权限没变，大概率是底层文件系统不支持 POSIX 权限，或挂载时加了压制参数。
检查挂载选项：
——
会强制覆盖文件权限位
NTFS/FAT32/UDB 分区默认无 uid/gid 概念，Linux 通过挂载参数模拟（如
），此时直接
无效
容器中若用 rootless mode 或 user namespace，
某些 UID 可能被映射拦截，
可查映射范围
SELinux/AppArmor 正在静默拒绝访问
权限位全对，
却显示 context 异常，或者
有拒绝日志——说明 MAC（强制访问控制）在起作用，它比传统权限更优先。
临时验证：用
（SELinux）或
（AppArmor）关闭策略，看问题是否消失
不要长期禁用，应修正策略：
解析拒绝原因，再用
生成新规则
常见坑：Web 服务器访问 NFS 共享目录时，SELinux 默认禁止
或
未开启
权限不生效从来不是单一原因，而是权限层（POSIX）、打开态（file descriptor）、存储层（mount options）、安全层（SELinux）四者之一或多个叠加的结果。最省时间的做法是按顺序跑一遍
、
、
、
，别跳步。
statls -lls -l /path/to/filelstat /path/to/fileAccessUidGidls -lchmod 644 *.confecho *.confopen()chmod 000lsof +D /pathlsof -p systemctl reloadSIGHUPstrace -e trace=openat,open -p chmodstatfindmnt -t ext4,xfs,btrfs | grep -E "(noexec|nosuid|noacl|mode=)"mode=uid=1000,gid=1000,fmask=0133chmodchown/proc/self/uid_mapls -Zdmesg | grep -i avcsetenforce 0aa-complain /path/to/binausearch -m avc -ts recent | audit2whyaudit2allowhttpd_can_network_connectuse_nfsstatlsoffindmntls -Z && dmesg