nfs挂载提示“access denied by server”的根本原因是服务器端/etc/exports配置错误，包括路径不绝对或含尾部斜杠、客户端ip未精确匹配、缺少fsid=0，以及未执行exportfs -ra重载。
为什么 NFS 挂载后提示 access denied by server
这是最常遇到的权限错误，根本原因不是客户端配错了，而是服务器端的 /etc/exports 条目没写对。NFSv4 默认启用 root_squash，且路径必须绝对、精确匹配——哪怕多一个斜杠（如 /data/ vs /data）都会拒绝。
实操建议：
-
/etc/exports中的共享路径必须是真实存在的绝对路径，且不带尾部斜杠 - 客户端 IP 或网段要写全，比如用
192.168.1.0/24而不是192.168.1.* - 务必加上
fsid=0（NFSv4 根文件系统标识），否则 v4 客户端可能无法定位根导出点 - 修改后必须运行
exportfs -ra重载，而不是只重启nfs-server服务
如何确认 NFS 服务已正确监听并导出目录
光看 systemctl status nfs-server 是不够的，它只说明进程在跑，不代表导出生效。得从服务端和客户端两个角度交叉验证。
服务端检查：
- 运行
exportfs -v查看当前实际导出的路径、选项和客户端范围 - 用
showmount -e localhost模拟客户端查询，确认能列出共享目录 - 检查
rpcbind是否运行（NFSv3 依赖它；NFSv4 可选，但某些发行版仍要求）
客户端辅助验证：
-
showmount -e <server-ip></server-ip>必须返回非空结果，否则别急着挂载 - 如果超时，先
telnet <server-ip> 2049</server-ip>测试端口连通性（NFS 主端口）
挂载时该用 nfs 还是 nfs4 类型？关键区别在哪
用错类型会导致挂载成功但无法访问子目录、或报 Stale file handle。本质区别在于协议层级和路径解析逻辑。
实操建议：
- 服务端配置了
fsid=0且导出路径为/data，客户端应使用nfs4类型，并挂载到/mnt/data，然后直接访问/mnt/data/subdir—— NFSv4 把所有导出视为同一命名空间下的子树 - 若用
nfs（即 v3）类型，则必须严格按服务端导出路径挂载，比如导出的是/data/project，就得挂载server:/data/project，不能只写server:/data -
mount -t nfs4会自动绕过rpcbind，适合防火墙受限环境；但若服务端只开 2049 端口，nfs类型可能因连不上 111 端口而失败
挂载后文件属主显示为 nobody:nogroup 怎么办
这不是挂载失败，而是 NFS 的 UID/GID 映射机制在起作用。默认启用 root_squash，且当客户端用户 UID 在服务端不存在时，就 fallback 到匿名用户。
解决方向分两种场景：
- 开发/测试环境需保持用户一致：确保客户端和服务器上同名用户 UID/GID 完全相同（查
id username），并改用no_root_squash（仅限可信内网） - 生产环境强调隔离：保留
root_squash，在服务端/etc/exports加anonuid=1001,anongid=1001，再创建对应 UID 的专用用户（如nfsuser），统一管控权限 - 避免用
all_squash，它会让所有用户（包括 root）都降权，容易导致脚本执行失败
NFS 共享看似简单，但每个环节都依赖两端配置的精确咬合：导出路径的拼写、协议版本的选择、UID 映射策略、甚至防火墙放行的端口组合——漏掉任意一环，都会表现为“能 ping 通、能 showmount、就是挂不上或挂上打不开”。
