我刚刚花了几个小时试图弄清楚为什么 NFS 导出无法在 Proxmox（基于 Debian）服务器上工作。在这种情况下，“无法工作”意味着客户端上的 mount 命令超时。经过一番挖掘（dmesg），我发现rpc.mountd服务器在启动后立即发生段错误。然后我四处搜索，/etc/mtab然后我找到了我真正开始困惑的地方：
$ ls -l /etc/mtab
lrwxrwxrwx 1 root root 19 Jan 30 15:08 /etc/mtab -> ../proc/self/mounts
$ cat /etc/mtab
cat: /etc/mtab: No such file or directory
/etc/mtab无论出于什么原因，相对的链接到../proc/self/mounts。如果我将其设为绝对链接
$ sudo ln -sfn /proc/self/mounts /etc/mtab
$ ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 Jan 30 15:10 /etc/mtab -> /proc/self/mounts
$ cat /etc/mtab
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
...
然后 NFS 导出就开始按预期运行。
在检查其他基于 Debian 的机器（以及其他运行 Proxmox 的机器）时，我发现它们也有/etc/mtab一个相对符号链接，并且可以正常工作。这台机器的“特殊”之处在于它使用虚拟文件系统，也适用于根文件系统。所以我只能假设是这个原因破坏了链接。
到目前为止，让这个链接绝对化似乎没有什么坏处，但我更想了解背后的原因。因此，以下是实际问题：
- 为什么
/etc/mtab相对的链接？这是为了简化 chroot 还是别的什么？ - 把它绝对化有什么不对吗？
- ZFS（假设这确实是根本原因）如何破坏这个链接？
答案1
使用绝对符号链接可能会有问题，尤其是在安装到非默认位置时。
opensuse:/mnt/etc # ls -l
total 0
lrwxrwxrwx 1 root root 17 Jan 30 20:07 absolute_mtab -> /proc/self/mounts
lrwxrwxrwx 1 root root 19 Jan 30 20:06 mtab -> ../proc/self/mounts
绝对符号链接可能有效，但它指向的是主机自己的/proc/目录，这显然是大忌，因为如果处理不当，可能会造成大麻烦。另一方面，相对符号链接不起作用，因为/mnt/proc在这种情况下没有，但这不是问题，或者至少不应该是个问题。
文件系统层次结构标准 (FHS) 要求或强制/etc/必须/proc/位于/根目录的顶部，如果它们不在顶部，则被视为无效。
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html
FHS 的另一个重要声明是：
如果安装了相应的子系统，则以下文件或文件的符号链接必须位于 /etc 中：
这意味着，/etc/mtab如果安装了用于动态挂载文件系统的子系统，它就必须存在，大多数现代 Linux 操作系统都是这种情况。
但是，就 FHS 而言/etc，重新挂载到的目录/mnt/etc不是有效/etc目录，因此仅使用相对符号链接来确保没有人在事故中使用或更改文件是有意义的。
。
我不确定你为什么会在这里遇到段错误，但我猜这要么是一个错误，要么是你的一般配置有问题。我倾向于认为这更像是一个软件错误。你可以尝试更新你的软件或将此错误报告给其创建者。
答案2
看起来只有我一个人（再次：S）。我已经在虚拟机中安装了 Proxmox，并且根文件系统也位于 ZFS 上，以查明发生了什么。起初，一切都正常，/etc/mtab指向相对位置../proc/self/mounts并正常工作。检查故障系统时，我发现前段时间我不小心，当时我拍摄了根文件系统 (/) 数据集的快照并将其发送到辅助池进行备份。我忘记禁用canmount接收数据集上的属性。这起初没有问题，但经过一段时间的重新启动后，ZFS 挂载了原始根数据集和备份数据集到 /。有趣的是，系统大部分时间都正常工作。但显然一个后果是/etc/mtab相对链接不再起作用，导致 NFS 服务器出现段错误。
在虚拟机上，我可以通过添加第二个硬盘、在其上创建池、向其发送和接收 rpool/ROOT/pve-1 的快照并重新启动来重现此行为：
重新启动以打破它...
应用修复，即禁用备份数据集的自动挂载：
重新启动以解决问题...
一切又好了。