Linux文件夹共享设置方法详解

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《Linux文件夹共享设置教程》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

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 必须返回非空结果，否则别急着挂载
• 如果超时，先 telnet 2049 测试端口连通性（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、就是挂不上或挂上打不开”。

理论要掌握，实操不能落！以上关于《Linux文件夹共享设置方法详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！