nfs不是同步工具，仅提供远程目录挂载，存在修改冲突、缓存不一致和无版本控制风险；常见问题包括服务名称混淆（rpc.statd vs rpcbind）、exports语法错误、防火墙未放行实际端口、默认缓存导致文件可见性异常，多客户端写同一文件必然出错，需改用rsync/ansible/glusterfs等方案。
直接说结论：NFS 不是同步工具，它只是让远程目录像本地磁盘一样挂载——所有服务器看到的是同一份文件，但修改冲突、缓存不一致、无版本控制，稍不注意就会丢数据。
为什么 nfs-utils 装了却 mount 失败？常见权限与服务状态问题
NFS 依赖两个核心服务：rpcbind（旧版）或 rpc.statd（新版） + nfs-server。CentOS 8+/RHEL 9 默认用 rpc.statd，但很多教程仍写 rpcbind，导致 systemctl 启动失败或端口监听异常。
- 先确认服务真实名称：
systemctl list-unit-files | grep -E "(nfs|rpc)"，重点关注nfs-server.service和rpc-statd.service -
exportfs -r前必须确保/etc/exports语法正确：客户端地址不能写域名（除非所有机器都配了 hosts 或内网 DNS），推荐用 CIDR 段如192.168.1.0/24 - 防火墙要放行的不是 “nfs” 服务名，而是实际端口：
rpcinfo -p localhost查出nfs、mountd、nlockmgr对应的端口号（通常是随机高位端口），或直接开放2049/tcp+2049/udp并启用rpc-bind的固定端口模式（需改/etc/sysconfig/nfs）
mount -t nfs 成功但写入慢 / 文件看不见？排查挂载选项与缓存行为
NFS 默认启用 write cache 和 readdir 缓存，多客户端同时读写时极易出现「A 刚创建的文件，B 立即 ls 不见」或「B 删除后 A 还能 cat」——这不是 bug，是 NFS 协议设计使然。
- 生产环境务必加选项：
mount -t nfs -o rw,hard,intr,rsize=65536,wsize=65536,ac,actimeo=1,nolock 192.168.1.10:/data /mnt/nfs -
ac（attribute cache）和actimeo=1强制 1 秒刷新元数据，避免 ls 不更新；nolock禁用rpc.lockd（否则内核会尝试分布式文件锁，而多数 NFS 服务端未配或不兼容） - 若用 NFSv4，可省略
nolock，但必须保证服务端/etc/exports显式声明fsid=0，且客户端 mount 时不要加nfsvers=3—— 混用 v3/v4 会导致stale file handle错误
多个服务器同时写同一个文件？别这么干，真要协同请换方案
NFS 没有原子性写协调机制。两个进程同时 echo "a" >> log.txt，结果可能只有一次写入生效，或内容错乱。这不是配置能解决的问题，是协议层限制。
- 日志类场景：用
syslog-ng或rsyslog转发到中心节点，各服务器只写本地 socket，不直写 NFS 目录 - 配置文件分发：用
rsync + inotifywait或 Ansiblecopy模块推送到各服务器本地路径，再通过软链指向统一入口 - 真需要多写共享存储：上
GlusterFS（支持条带+复制）、CephFS（POSIX 兼容更强），或干脆用对象存储 + 应用层逻辑处理并发
最常被忽略的一点：NFS 客户端挂载后，df -h 看到的可用空间永远是服务端的剩余空间，但服务端磁盘打满时，所有客户端的 write() 系统调用会卡住甚至 hang 死——没有超时、不报错、只等。监控必须同时抓服务端磁盘 + 客户端 rpc.mountd 请求延迟，不能只盯一个端。
