linux文件无法访问主因是目录执行权限（x）缺失、组成员未实时生效、umask或default acl干扰，默认权限机制比单纯chmod数值更关键。
Linux中用户文件无法访问，多数情况不是权限数值设错了，而是权限继承机制没理清——尤其是涉及目录创建、组成员变动、umask设置和默认ACL时。
目录的执行权限（x）才是关键
很多人只关注文件的读写权限，却忽略目录本身必须有执行（x）权限才能进入和遍历。即使文件权限是644，若其所在目录没有x权限，用户仍无法cd进入或ls列出内容，自然也打不开里面的文件。
- 检查路径上每一级目录是否都有对应用户的x权限（对目录而言，x=可进入/可遍历）
- 用namei -l /path/to/file一次性查看完整路径各层权限和所有者
- 常见误操作：把父目录权限设为750但用户不在该组，或误删了目录的x位（如chmod 644 dir/）
umask影响新建文件/目录的默认权限
用户创建文件时，系统不会直接套用777或666，而是用umask值做掩码运算。例如umask 002，新建目录得775，文件得664；若umask是022，则目录755、文件644——这直接影响同组用户能否后续写入。
- 查看当前umask：umask（数字）或umask -S（符号）
- 临时修改：umask 002；永久生效需写入~/.bashrc或/etc/profile（注意区分交互式与非交互式shell）
- 脚本或服务（如nginx、git-daemon）常以独立环境运行，它们的umask可能与登录用户不同，需单独配置
组权限不生效？先确认用户是否“实时”在组里
把用户加入新组后，已有登录会话不会自动获得新组身份。必须重新登录（或用newgrp临时切换），否则group列表里看不到，组权限也就形同虚设。
- 验证方式：id -nG看当前会话所属组，对比getent group groupname确认用户确实在组中
- SSH登录、su -、或图形界面重登才能刷新组信息；仅用su不带-参数不会加载新组
- systemd用户服务、cron任务等也沿用启动时的组上下文，需注意触发时机
ACL默认项（default ACL）会覆盖umask行为
若父目录设置了default ACL（如setfacl -d -m g:dev:rwx /project），那么所有新建子项将自动继承该ACL规则，此时umask会被绕过，权限结果可能与预期不符。
- 检查是否有default ACL：getfacl /path | grep "default:"
- default ACL只影响新建项，不影响已存在文件；但若同时设了mask，实际生效权限还受mask限制
- 清理默认ACL：setfacl -k /path（删除default条目）或setfacl -b /path（清空全部ACL）
权限问题看似是数字组合，实则是创建上下文、进程身份、继承规则三者叠加的结果。定位时从路径逐级查起，优先确认x权限、组成员状态和umask/AACL配置，比盲目chmod更高效。
