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