连上共享存储，ls -l 一看，文件权限那一栏全是 ----------——一个 r、一个 w、一个 x 都没有。按老经验，这文件"谁也读不了、谁也写不了"。可你伸手去读，读得出来；去写，也写得进去。权限显示和实际行为完全对不上，这时候该信哪个？
信行为。权限那一栏，只是权限模型的一种。
现象
具体表现：
- 在某个挂载点（多为网络共享存储）上，
ls -l输出的权限位是----------； - 直觉判断：文件不可读写；
- 实际测试
cat、echo >、编辑保存，全都正常； - 同一个挂载点上，可能所有文件都是这副"没权限"的样子。
根因
关键在于：这个文件系统用的是 NFSv4 ACL，而不是传统的 mode bits。
传统的 Unix 权限，就是大家熟悉的那九个位：属主/属组/其他人的 rwx，ls -l 显示的就是它。这套模型简单，但表达能力有限——它只能按"属主、一个属组、其他人"这三类来授权，没法精细到"给用户 A 读写、给用户 B 只读、给组 C 只执行"这种粒度。
NFSv4 引入了更丰富的 ACL（访问控制列表），可以为任意用户/组分别指定权限，还能继承、还能有拒绝项。这套模型在很多 NAS 和共享存储上是默认的。
问题出在查看方式上：传统的 ls -l 读的是那九个 mode bits。当文件系统的权限主模型是 NFSv4 ACL 时，这九个位可能根本没有被设置或映射——它们显示出来就是空的，于是变成 ----------。但这些位是空的不代表没有权限，权限实际由那份 ACL 定义着，ls -l 看不到而已。
一句话：---------- 不是"没有权限"，而是"传统权限位里没有记录，真正的权限在 ACL 里"。
解决
不要用传统权限查看去判断 NFSv4 ACL 环境下的权限问题。要么用支持 ACL 的方式看，要么直接实测。
查看 NFSv4 ACL（需要 nfs4-acl-tools）：
# 查看某个文件/目录的 NFSv4 ACL
nfs4_getfacl /path/to/file
# 典型输出会列出每条 ACE（访问控制项），例如：
# A::OWNER@:rwatTnNcCy
# A::GROUP@:rxtncy
# A:g:1001:rxtncy
nfs4_getfacl 会把真正的 ACL 逐条列出来：A 表示允许（D 表示拒绝），后面跟着用户/组的标识和权限字母。想知道"谁能读、谁能写"，看这个才是准的。
修改权限也要用对应的工具，别用 chmod（chmod 改的是 mode bits，在纯 ACL 环境里可能无效或不生效）：
# 精确授权：让某个用户对该文件可读写
nfs4_setfacl -a A::1001:rw /path/to/file
# 或对目录加上继承标志
最直接的办法是实测读写：
# 以具体身份试读、试写，结果比权限位可信
cat /path/to/file > /dev/null && echo "可读"
touch /path/to/dir/testfile && echo "可写" && rm /path/to/dir/testfile
需要注意：你以 root 测出来的结果，可能不代表普通用户的结果。要验证某个业务账号的权限，最好以那个账号身份（sudo -u <用户>）去测，才贴近真实情况。
延伸与预防
这条坑的通用价值，是那句容易被忽略的话：传统的权限位只是权限模型的一种，别拿它解释一切。
权限模型有很多套：Unix mode bits、POSIX ACL、NFSv4 ACL、Windows 的 DACL、SELinux/AppArmor 的强制访问控制……它们可以叠加，也可能互相覆盖。你在某一层看到的"有/无权限"，未必是最终决定行为的那一层。前面讲过的 SELinux 布尔值、文件上下文，也是同一类问题——表面权限和实际权限分属不同机制。
所以遇到"权限显示和实际行为不符"，别急着改权限，先问：这个文件系统/这个环境，用的是哪套权限模型？我看的这一栏，是它生效的那一栏吗？ 用对工具查看、以真实身份实测，比盯着 ls -l 猜要靠谱得多。
预防上，一句话：判断权限，永远以"以目标身份实测"为准，其他都是线索，不是结论。