☰

NFSv4 fsid 选项和导出根目录的目的

tag-icon • tag-icon nfs4
NFSv4 fsid 选项和导出根目录的目的

我的文件服务器只有一个大分区在 /exports 下共享内容。因此，使用旧式 NFSv3 导出，我有：

/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

因此我决定切换到 NFSv4 风格并将其更改为：

/exports          192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc              192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.

然后，我将挂载命令更改为排除/exports。果然/etc是无法挂载的（虽然它没有出错，只是锁定直到被中断）。但是，正如我所料，/exports的 ACL 仍然向下继承，所有共享都是只读的，并且 root 在所有地方都被压缩了。

我也尝试将 ACL 更改为/exports/root单台机器，但没有什么区别。

因此，除了能够为无法确定此类标识符的文件系统提供唯一标识符之外，使用以下命令定义导出根还有什么意义fsid=0：

  • 这样做会降低共享设置方面的灵活性（即继承问题，除非在不同的文件系统上并且您使用nocrossmount？）。
  • 假设采用旧式 NFSv3 设置，您仍然无法挂载，/etc那么它提供什么额外的安全性？

仅当仅仅是用于在其中安装并使用不同的 acl 导出的单独文件系统的安装区域fsid=0时才有意义？/exports

在我看来，NFS 服务器的设置已经颠倒过来了。以前在 Solaris 上，所有共享内容都直接挂载在 下/export，然后共享出去。服务器会/home/user绑定挂载到/export/home/user。但现在/home是真正的文件系统挂载位置，并绑定挂载在 下/exports。

它是否正确？

请注意：以上示例仅用于说明目的，因此请不要评论不使用的明智性no_squash_root，我知道。

非常感谢。

答案1

这是 NFS“挂载”协议工作方式的架构变化。

在 NFSv2/v3 中，有一个完全独立的“MOUNT”RPC 协议，允许客户端通过其路径获取任何导出文件系统的文件句柄。但在后续的 WebNFS（以及后来的 NFSv4）中，挂载被更改为带内 NFS 操作，同时该操作被更改为返回单个“根”文件句柄，然后所有路径查找都从该根开始。（实际上，WebNFS 有两个这样的根，另一个是 nfs:// URL 的“公共”根，它没有进入 NFSv4。）

因此，为了使“PUTROOTFH”操作起作用，必须是某种根文件系统，因为不可能再跳过这些步骤——所有路径遍历都是一系列 [PUTROOTFH、LOOKUP、LOOKUP、...、LOOKUP、OPEN] 复合操作。这反映了 Plan9 的 9p 以及 SMBv2/3。

（所有这些都意味着，在这种风格下，导出的文件系统路径与根目录相关，例如，你的 /exports/home 被挂载为“foo:/home”，不是作为“foo:/exports/home”.)

缺少 MOUNT(path) 操作也是“crossmnt”的隐含原因，因为不是剩下的任何需要安装的东西，都只是从根目录向下“查找”。

实际上，NFSv4 可以使用任一样式 - 如果未定义“fsid=0”导出，则 Linux 内核（2.6.33 或更高版本）/将自动为您生成虚拟根目录其中包含除常规导出位置的挂载之外的任何内容。（这还具有在 NFSv3 和 NFSv4 之间保留相同挂载路径的优点。）换句话说，您实际上可以继续使用原始的 v3 样式配置。

相关内容