NFS

NFS 导出把服务器文件系统路径与客户端及访问策略关联起来。在 Linux 上，exportfs 根据 /etc/exports、/etc/exports.d 下合格文件或命令行更新，维护 /var/lib/nfs/etab。rpc.mountd 是守护进程，不是第三份配置文件；其 MOUNT 服务与旧版协议流程有关，NFSv4 挂载并不要求这个独立服务。应先明确版本和服务职责，再解释客户端的结果。 配置文本可能与有效导出不同，但这只是拒绝访问的一种原因，不能从文件看起来正确就断定导出表过期。还要核对目标服务器、协议、导出策略、身份及文件权限。服务器的持久性和客户端缓存也要分开：应用看到一次写入成功，并不单独证明服务器已把相应数据提交到稳定存储。目录可见、访问获准和写入可恢复，是不同层次的事实。 文件与表 /etc/exports 的条目把目录与客户端及选项关联。/srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash) 展示一个网络，后面还能追加有自己选项的客户端组。主机名、网段和 netgroup 有各自匹配规则。exportfs -ra 会协调配置与导出，但其他 exportfs 操作或服务管理也能应用改变；它不是唯一生效途径，不能把所有差异都归因于忘记运行这一条。 showmount -e 向服务器 MNT 服务询问公布的导出。信息完整性取决于实现，只有 NFSv4 的服务器甚至可能不暴露此服务。因此它既不是完整有效策略转储，也不证明某客户端一定能访问共享。原文四条配置对三条导出以及 NOENT 的故事没有找回原始运行记录；缺失导出也不能保证所有客户端总收到同一个错误码。诊断应保留实际返回信息。 选项真正决定了什么 导出默认只读，rw 才允许写入，但文件权限及其他控制仍然生效。sync 约束服务器按稳定存储要求回复，async 则允许改动提交前回复，崩溃可能丢失已确认的数据。两者都不会消除客户端缓存，也不让每次应用写入自动变成同步持久提交。nfs-utils 在 1.0.0 版本之后把默认从 async 改为 sync；理解版本历史时要与实际客户端操作分开。 ...