在 NFSv4 教程中，经常会看到将共享根目录导出到整个子网的建议，类似于这来自 Arch 维基：
/etc/导出：
/srv/nfs 192.168.1.0/24(rw,sync,crossmnt,fsid=0,no_subtree_check)
/srv/nfs/music 192.168.1.0/24(rw,sync,no_subtree_check)
/srv/nfs/public 192.168.1.0/24(ro,all_squash,insecure,no_subtree_check) desktop(rw,sync,all_squash,anonuid=99,anongid=99,no_subtree_check)
会不会更安全不是有第一行吗？ （在我的问题中，当我提到“第一行”时，我指的是上面代码片段中的第一个导出行。）
对于 NFSv4，fsid=0 是可选的，这似乎主要是为了缩短路径（通过将 /srv/nfs 转换为 /）。在我的初步测试中，只要您使用 /srv/nfs，导出就可以在没有第一行的情况下正常工作。第一行提供哪些重要功能（如果有）？
当我们知道至少还有一个绑定挂载时，我还想考虑一下这个例子：
/srv/nfs/projects
（假设“项目”的内容与音乐绑定安装不同，是敏感的。）
第一个导出行，如上面所写，似乎使 LAN 上的每个客户端都可以访问整个导出的文件系统，尤其是使用 crossmnt 和 no_subtree_check 时。我并不是建议忽略所有者和组权限，但我认为导出在没有第一行的情况下也可以正常工作，并且其他绑定安装在 /srv/nfs 下（例如 /srv/nfs/projects）不会不必要地向整个子网开放，从而暴露对所有者和组权限的任何潜在监督。
当然，可以添加与此类似的导出，正确共享“项目”：
/etc/导出：
/srv/nfs/projects 192.168.1.123(rw,sync,root_squash,subtree_check)
这条新线是否受到第一线的影响？我看不出第一条出口线有什么重要作用。
如果有那条线是有帮助或推荐，这样做是否明智？
/srv/nfs 192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash)
接下来的更具体的导出将覆盖这一导出是否正确？例如，即使第一行更改为 ro 并变得更加严格（如下例所示），以下行是否会正确授予 rw 对“音乐”的访问权限？
/srv/nfs 192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash)
/srv/nfs/music 192.168.1.2(rw,sync,no_subtree_check)
列出出口商品时顺序重要吗？什么决定优先级？更具体的地址（例如，192.168.1.2）是否会覆盖更一般的地址（192.168.1.0/24）？
注意：这个问题有一个单一的主题，它可能会使用一个更好的标题来明确这一点，但到目前为止我还没有想出正确的标题。我欢迎编辑。
答案1
这导出的手册页说一下fsid参数
NFS 需要能够识别它导出的每个文件系统。通常它会使用文件系统的 UUID（如果文件系统有这样的东西）或保存文件系统的设备的设备号（如果文件系统存储在设备上）。
由于并非所有文件系统都存储在设备上，并且并非所有文件系统都有 UUID，因此有时需要显式告诉 NFS 如何识别文件系统。这是通过
fsid=选项完成的。
现在我们知道为什么fsid有时需要该参数，让我们看看手册页中有关 NFSv4 的内容（这部分与旧版本有很大不同）：
对于 NFSv4，有一个独特的文件系统，它是所有导出文件系统的根。这与
fsid=root或fsid=0两者指定的含义完全相同。
换句话说，对于 NFSv4，示例中的第一行定义一个基点，服务器导出到某个客户端的所有目录都位于该基点下。乍一看，与允许导出任何目录的 NFSv3 的灵活性相比，这听起来像是倒退了一步。但是，您可以轻松地将已在其他位置安装的目录放入此目录中。只需添加如下一行即可/etc/fstab
/path/to/music/dir /srv/nfs/music none rbind 0 0
并运行mount -a以挂载新的文件系统。新方法本质上充当伪根文件系统，防止客户端访问该目录之外的数据，从而允许 NFS 服务器轻松检查是否应授予客户端访问文件的权限，从而降低复杂性，同时提高安全性。