认证与身份降级是两件事
NFS 里常被混为一谈的两组参数其实分工不同。sec= 决定本次访问用什么凭据：sec=sys 就是无条件相信客户端报上来的 UID/GID，而 sec=krb5 系列要求先通过 Kerberos 拿到票据。squash 系列选项决定服务端拿到这个身份后怎么改：root_squash 把 UID 0 换成匿名，all_squash 则把所有人一律换成匿名。理解了这条分工，共享目录里文件的属主为何是 nobody 就一目了然。
基本信息
| 适用平台 | Linux NFS 服务端与客户端（nfs-utils） |
|---|---|
| 认证参数 | sec=sys（默认）/ krb5 / krb5i / krb5p |
| 降级参数 | root_squash、no_root_squash、all_squash |
| 匿名身份 | anonuid / anongid，默认 65534（nobody/nogroup） |
| 核对命令 | exportfs -v、cat /proc/mounts、ls -ln |
常见组合的效果
| 导出选项 | 客户端 root 在服务端变成 | 适用场景 |
|---|---|---|
| root_squash（默认） | 匿名用户 nobody | 绝大多数共享，尤其多租户与只读分发 |
| no_root_squash | 仍然是 root | 受控测试、需要备份工具保留属主 |
| all_squash | 匿名用户，其他账号也一起降级 | 公共只读仓库、未知身份客户端 |
| all_squash + anonuid/anongid | 指定 UID/GID（如 1001） | 希望匿名写入落在固定属主名下 |
| no_all_squash | 保持原 UID/GID（默认行为） | 已统一账号体系的内网 |
导出与挂载示例
导出与挂载示例
# 服务端：读写共享，客户端 root 降级为匿名，其他账号保持原 UID
/data/app 10.0.0.0/24(rw,sync,root_squash,no_all_squash)
# 服务端：公共只读仓库，任何人一律压到 nobody 读
/data/repo *(ro,sync,all_squash,anonuid=65534,anongid=65534)
# 客户端：挂载后立刻确认身份映射结果
mount -t nfs 10.0.0.10:/data/app /mnt/app && ls -ln /mnt/appsec=krb5 走的是认证，不再是 IP 信任：服务端需要 krb5p/krb5i 对应的主机 keytab 与 nfs/<主机名> 主体，客户端需要 gssd 与 idmapd 在跑。服务端导出与客户端挂载的 sec 值必须匹配，否则挂载阶段就会报 access denied by server 而不是等到读写才失败。
检查映射结果
检查映射结果
exportfs -v # 看每条导出生效的 squash 与 sec
getent passwd 65534 # 确认服务端匿名账号是什么
ls -ln /srv/data # 看现有文件属主的 UID 数字
tail -n 30 /var/log/messages # RHEL 系看 nfsd 拒绝记录
journalctl -u nfs-server -n 30 # Debian 系看服务日志匿名映射的连带影响
一旦所有写入都以 nobody 落盘，服务端目录就需要对 nobody 开放写权限，否则客户端会看到挂载正常却写不进去。反过来，如果 no_all_squash 生效而客户端 UID 在服务端不存在，新建文件会显示成一串数字属主，后续用名称做权限管理的策略就会失效。所以匿名映射不是单独一个开关，它同时要求你重新审视服务端目录的属主与权限位。