我的胡子现在已经是纯灰色了，我还记得自己使用 NFS 的这几十年，这里我引用了原始的 RFC这为我们今天的 NFS 提供了基础RFC1094。 当然，从那时起已经过去了三十年，所以问题是：
在过渡期现在是否可以通过配置选项从服务器端解释链接？这肯定能解决我的许多关于客户端链接解释的问题！
或者，我是不是太糊涂了，我所引用的内容已经过时了，而且它实际上是默认在服务器端解析的，而我在故障排除时只是在兔子洞里追逐兔子？
如果它仍然是老式的，并且是在客户端解释的，并且如果没有启用服务器端解释的选项，那么使用相对链接而不是绝对链接是否有帮助？
谢谢。
答案1
符号链接始终由客户端解析。原因有几个。首先，NFS 协议有一个文件句柄的概念。每个句柄指向一个文件系统对象，该对象可以是目录、文件或符号链接（以及其他一些对象）。此外，NFSv4.1规范明确指出：
无论是由 NFS 客户端创建还是在服务器本地创建，符号链接中的数据在创建时都不会被解释，而只是被存储。
其次，通过处理服务器端的符号链接，必须考虑额外的权限规则，因为符号链接可能指向导出的文件系统的外部。
确实，SAMBA 服务器没有遵循符号链接的选项。这是因为 (a) 原始的 MS 文件系统没有符号链接的概念，以及 (b) 符号链接作为文件系统对象类型被添加进来中小企业。顺便说一下，此行为符合 NFS 解释：
服务器绝不能评估符号链接。
如果需要，有几个用户空间 NFS 服务器允许自定义文件系统实现：
- nfs-ganescha
- nfs4j（我是开发人员之一）
如果有好的解决服务器端符号链接的原因，可以添加。
答案2
网络上有两台计算机，它们具有相同的 NFS 安装设置，指向服务器。服务器上有从一个导出目录到另一个导出目录的符号链接。在一个客户端上，链接工作正常，而在另一个客户端上，它们不可靠。我怀疑，由于工作客户端有新版本的 NFS（使用相同的协议），因此修复了一个错误。理论上，请求应该发送到服务器并在那里进行解释，因为这是导出过程。如果客户端将符号链接放在文件夹中，那么它在其他客户端上可能会被破坏。但是，服务器符号链接应该可以工作。这通常表明需要一种用于网络共享的特殊类型的符号链接。类似于服务器符号链接。