systemd：无法挂载 NFS 共享：mount.nfs：网络在启动过程稍后之前无法访问

Question 1

这对我来说适用于 systemd。automount,延迟挂载requires请求，直到网络联机。

我不确定nofail.我使用它没有问题，但似乎不太正确。应该没有必要requires……也许有人有想法。

10.0.0.110:/export/3T  /mnt/3T  nfs nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0

Answer

这对我来说适用于 systemd。automount,延迟挂载requires请求，直到网络联机。

我不确定nofail.我使用它没有问题，但似乎不太正确。应该没有必要requires……也许有人有想法。

10.0.0.110:/export/3T  /mnt/3T  nfs nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0

Question 2

在 CentOS 7 上，网络文件系统挂载依赖于network-online.target.一旦接口启动并设置了 IP，即可到达
。这假定第一个接口上的第一个 IP 足以解析主机名。然而，情况并非必须如此。network-online.target

我们可以编写systemd services测试网络是否应该被标记为“向上” 并使network-online.target 依赖的在该服务上。

对于模板，请查看： https://gitlab.com/ggeurts/extend-network-online.target

Answer

在 CentOS 7 上，网络文件系统挂载依赖于network-online.target.一旦接口启动并设置了 IP，即可到达
。这假定第一个接口上的第一个 IP 足以解析主机名。然而，情况并非必须如此。network-online.target

我们可以编写systemd services测试网络是否应该被标记为“向上” 并使network-online.target 依赖的在该服务上。

对于模板，请查看： https://gitlab.com/ggeurts/extend-network-online.target

Question 3

我遇到了类似的问题，特别是 NFS 挂载对 network-online.target 的依赖。

这是特别有问题的，因为我的 Ubuntu 桌面 network-online.target 由 NetworkManager 控制，这将表明甚至在通过 DHCP 安装任何 DNS 或默认路由之前就已经达到了 network-online.target。这里的问题是，如果 IP 层没有到远程目标的默认路由，则从通过 fstab 创建的生成器单元或手动制作的 .mount 单元发出的任何 mount.nfs 命令都将失败，并显示“网络无法访问”。

我想要一个能够无延迟地可靠启动的系统，无论 NFS 是否已成功安装，都能将我带到桌面。此外，我希望当网络可用或 NFS 服务器突然出现在网络上时，NFS 能够自动建立挂载。

实现这个目标比我预想的要困难，但我会分享我的经验，因为其他人可能会发现它有用。

我已从 fstab 中删除了除“/”之外的所有安装定义。我有一种感觉，fstab 正在下降，最终我们将看到所有挂载操作都通过 systemd 简单地执行。尽管生成器确实使 fstab 的使用变得“简单”。因此，我将所有 NFS 挂载移动到我自己创建的挂载单元中。我还发现 Nautilus 或 Nemo，选择你的毒药，不会在左侧“设备”窗格中显示 NFS 挂载，除非它们安装在用户主目录中或安装在 /media 中。当我最终让系统正常运行时，我希望使用 GUI 工具来管理文件。为此，我使用了将单个 NFS 挂载到服务器上，然后使用一组挂载单元的组合，这些挂载单元 --bind 将服务器中的每个导出挂载到我在台式机上想要的位置。当在底层 NFS 挂载点上创建绑定挂载时，systemd 实际上会在幕后创建 NFS 挂载。因此，我只有一个由系统启动的 NFS 挂载，它将 NFS 服务器的根目录附加到 /mnt。

为了克服启动时的依赖性，并在网络或服务器不可用时阻止任何 NFS 挂载超时，我从 mnt-NFS-mx.service 单元启动 NFS 挂载操作。

[Unit]
Description=Attempting to mount server 'mx' using NFS

After=network.target

[Service]
Type=oneshot

# Add a high metric default to 'lo' interface into route table.
# This prevents the mount command from failing with "Network unreachable" is case no external phy link is available.
ExecStart=-/bin/ip route add default dev lo metric 4294967295
ExecStart=/bin/mount 10.0.0.10:/mnt/ /mnt/NFS/mx -t nfs -o nolock,nfsvers=4,fg,retry=10000,hard,timeo=20,retrans=1

# Remove the default once the mount command is successful
ExecStop=-/bin/ip route del default dev lo metric 4294967295
ExecStopPost=-/bin/ip route del default dev lo metric 4294967295

[Install]
WantedBy=network.target

这是在启动时由 network.target 拉入的，并且必须在 network.target 之后启动，因为它添加了默认路由，以防止在找不到默认路由时 mount 命令失败。使用适当高的指标，在获取时不会干扰真正的默认值（仅供参考，该指标为最大值）。然后，它调用 NFS 安装，并且在安装命令运行时该服务将保持“激活”状态。如果安装了 NFS 服务器，该服务将停止并删除多余的默认路由。如果没有，它将永远挂起（大约 1 周），等待服务器。但这并不妨碍系统实现任何进一步的目标。请注意，这是仅限 NFSv4 的环境。如果需要早期版本，您必须确保所有 RPC 基础设施都已启动。我屏蔽了所有这些 RPC 服务，但是如果找不到此遗留环境的某些部分，NFS 挂载仍然会失败，因为它仍然希望与 RPC 的文件锁定交互，即使 NFSv4 不使用它。因此，mount 命令中需要“nolock”。看来这只是 NFS 挂载实现中的一个遗留问题。此外，我还将“timeo”和“retrans”选项调整为更积极的级别，有助于确保在“可用”默认路由可用时快速找到服务器。使用指定的设置，客户端等待 2 秒以获取响应，如果没有响应，则不会重新传输相同的请求。这可确保客户端不会进入指数退避，否则会导致每次尝试查找服务器之间的重传间隔增大。然而，由于重试计时器设置为 10000 分钟，它会立即使用相同的最大超时 2 秒再次尝试新的尝试......如此反复，直到获得连接。在我的系统上，我什至在到达 network-online.target 之前就看到所有 NFS 挂载就位并准备就绪。

假设在某个阶段 NFS 挂载。我有“mx”服务器根@ /mnt/NFS/mx/。由于安装部分中的“WantedBy=mnt-NFS-mx.service”，我的 mnt-NFS-mx.service 单元的激活会触发一系列绑定安装。示例如下：media-NAS_Public.mount

[Unit]
# To make remote NFS shares appear under the devices pane of Nemo
Description=--bind NFS NAS /Public onto /media/NAS_Public

DefaultDependencies=no

After=mnt-NFS-mx.service

[Mount]
What=/mnt/NFS/mx/shared_sun_NAS/Public
Where=/media/NAS_Public
Type=none
Options=bind,_netdev
TimeoutSec=0

[Install]
WantedBy=mnt-NFS-mx.service

在此安装单元中值得注意的是“DefaultDependency=no”与选项“_netdev”的结合使用。 _netdev 通常用于确保 systemd 理解该挂载单元实际上与网络相关，而不是本地文件系统的一部分。但是，这会在remote-fs-pre.target、network.target和network-online.target上添加After=的一系列默认依赖项，并且重要的是在remote-fs.target上添加Before=。这个 Before= 很麻烦，因为如果这些挂载单元没有成功或超时，这会阻止系统到达remote-fs.target！因此，使用“DefaultDependency=no”，可以消除这些依赖关系，并防止在启动时未直接启动该单元时启动挂起。我保留了 _netdev 选项作为辅助回忆录，该绑定挂载实际上将创建一个直接到挂载点目标的 NFS 挂载。

我在 /media 中创建了一堆这些 .mount 单元，也直接在我的个人文档目录等的主目录中创建了这些 .mount 单元。最后，我确保提前创建桌面计算机上的任何安装点，并且不可变在这些目录上设置标志 (chattr +i /media/NAS_Public) 以确保如果安装过程失败，则不会向这些位置写入任何内容。

虽然在我的例子中并不重要，但应该清楚的是，对这些绑定安装使用“DefaultDependency=no”将阻止必须具有 NFS 连接的应用程序的任何依赖关系逻辑意识到失败。话虽如此，可以使用 After=mnt-NFS-mx.service 作为替代品。我没试过这个。

归根结底，这为我提供了一个稳定且快速的启动系统，无论我的网络或服务器的状态如何，还有一个好处是，如果服务器故障得到纠正，安装将突然出现。

希望其他人发现这很有用。

Answer

我遇到了类似的问题，特别是 NFS 挂载对 network-online.target 的依赖。

这是特别有问题的，因为我的 Ubuntu 桌面 network-online.target 由 NetworkManager 控制，这将表明甚至在通过 DHCP 安装任何 DNS 或默认路由之前就已经达到了 network-online.target。这里的问题是，如果 IP 层没有到远程目标的默认路由，则从通过 fstab 创建的生成器单元或手动制作的 .mount 单元发出的任何 mount.nfs 命令都将失败，并显示“网络无法访问”。

我想要一个能够无延迟地可靠启动的系统，无论 NFS 是否已成功安装，都能将我带到桌面。此外，我希望当网络可用或 NFS 服务器突然出现在网络上时，NFS 能够自动建立挂载。

实现这个目标比我预想的要困难，但我会分享我的经验，因为其他人可能会发现它有用。

我已从 fstab 中删除了除“/”之外的所有安装定义。我有一种感觉，fstab 正在下降，最终我们将看到所有挂载操作都通过 systemd 简单地执行。尽管生成器确实使 fstab 的使用变得“简单”。因此，我将所有 NFS 挂载移动到我自己创建的挂载单元中。我还发现 Nautilus 或 Nemo，选择你的毒药，不会在左侧“设备”窗格中显示 NFS 挂载，除非它们安装在用户主目录中或安装在 /media 中。当我最终让系统正常运行时，我希望使用 GUI 工具来管理文件。为此，我使用了将单个 NFS 挂载到服务器上，然后使用一组挂载单元的组合，这些挂载单元 --bind 将服务器中的每个导出挂载到我在台式机上想要的位置。当在底层 NFS 挂载点上创建绑定挂载时，systemd 实际上会在幕后创建 NFS 挂载。因此，我只有一个由系统启动的 NFS 挂载，它将 NFS 服务器的根目录附加到 /mnt。

为了克服启动时的依赖性，并在网络或服务器不可用时阻止任何 NFS 挂载超时，我从 mnt-NFS-mx.service 单元启动 NFS 挂载操作。

[Unit]
Description=Attempting to mount server 'mx' using NFS

After=network.target

[Service]
Type=oneshot

# Add a high metric default to 'lo' interface into route table.
# This prevents the mount command from failing with "Network unreachable" is case no external phy link is available.
ExecStart=-/bin/ip route add default dev lo metric 4294967295
ExecStart=/bin/mount 10.0.0.10:/mnt/ /mnt/NFS/mx -t nfs -o nolock,nfsvers=4,fg,retry=10000,hard,timeo=20,retrans=1

# Remove the default once the mount command is successful
ExecStop=-/bin/ip route del default dev lo metric 4294967295
ExecStopPost=-/bin/ip route del default dev lo metric 4294967295

[Install]
WantedBy=network.target

这是在启动时由 network.target 拉入的，并且必须在 network.target 之后启动，因为它添加了默认路由，以防止在找不到默认路由时 mount 命令失败。使用适当高的指标，在获取时不会干扰真正的默认值（仅供参考，该指标为最大值）。然后，它调用 NFS 安装，并且在安装命令运行时该服务将保持“激活”状态。如果安装了 NFS 服务器，该服务将停止并删除多余的默认路由。如果没有，它将永远挂起（大约 1 周），等待服务器。但这并不妨碍系统实现任何进一步的目标。请注意，这是仅限 NFSv4 的环境。如果需要早期版本，您必须确保所有 RPC 基础设施都已启动。我屏蔽了所有这些 RPC 服务，但是如果找不到此遗留环境的某些部分，NFS 挂载仍然会失败，因为它仍然希望与 RPC 的文件锁定交互，即使 NFSv4 不使用它。因此，mount 命令中需要“nolock”。看来这只是 NFS 挂载实现中的一个遗留问题。此外，我还将“timeo”和“retrans”选项调整为更积极的级别，有助于确保在“可用”默认路由可用时快速找到服务器。使用指定的设置，客户端等待 2 秒以获取响应，如果没有响应，则不会重新传输相同的请求。这可确保客户端不会进入指数退避，否则会导致每次尝试查找服务器之间的重传间隔增大。然而，由于重试计时器设置为 10000 分钟，它会立即使用相同的最大超时 2 秒再次尝试新的尝试......如此反复，直到获得连接。在我的系统上，我什至在到达 network-online.target 之前就看到所有 NFS 挂载就位并准备就绪。

假设在某个阶段 NFS 挂载。我有“mx”服务器根@ /mnt/NFS/mx/。由于安装部分中的“WantedBy=mnt-NFS-mx.service”，我的 mnt-NFS-mx.service 单元的激活会触发一系列绑定安装。示例如下：media-NAS_Public.mount

[Unit]
# To make remote NFS shares appear under the devices pane of Nemo
Description=--bind NFS NAS /Public onto /media/NAS_Public

DefaultDependencies=no

After=mnt-NFS-mx.service

[Mount]
What=/mnt/NFS/mx/shared_sun_NAS/Public
Where=/media/NAS_Public
Type=none
Options=bind,_netdev
TimeoutSec=0

[Install]
WantedBy=mnt-NFS-mx.service

在此安装单元中值得注意的是“DefaultDependency=no”与选项“_netdev”的结合使用。 _netdev 通常用于确保 systemd 理解该挂载单元实际上与网络相关，而不是本地文件系统的一部分。但是，这会在remote-fs-pre.target、network.target和network-online.target上添加After=的一系列默认依赖项，并且重要的是在remote-fs.target上添加Before=。这个 Before= 很麻烦，因为如果这些挂载单元没有成功或超时，这会阻止系统到达remote-fs.target！因此，使用“DefaultDependency=no”，可以消除这些依赖关系，并防止在启动时未直接启动该单元时启动挂起。我保留了 _netdev 选项作为辅助回忆录，该绑定挂载实际上将创建一个直接到挂载点目标的 NFS 挂载。

我在 /media 中创建了一堆这些 .mount 单元，也直接在我的个人文档目录等的主目录中创建了这些 .mount 单元。最后，我确保提前创建桌面计算机上的任何安装点，并且不可变在这些目录上设置标志 (chattr +i /media/NAS_Public) 以确保如果安装过程失败，则不会向这些位置写入任何内容。

虽然在我的例子中并不重要，但应该清楚的是，对这些绑定安装使用“DefaultDependency=no”将阻止必须具有 NFS 连接的应用程序的任何依赖关系逻辑意识到失败。话虽如此，可以使用 After=mnt-NFS-mx.service 作为替代品。我没试过这个。

归根结底，这为我提供了一个稳定且快速的启动系统，无论我的网络或服务器的状态如何，还有一个好处是，如果服务器故障得到纠正，安装将突然出现。

希望其他人发现这很有用。

Question 4

我发现有效的方法是创建一个专用的 systemd 服务来完成挂载磁盘的工作，并忽略 systemd 的挂载功能。

这种方法的基础是：

NFS 可能由于一千个不同的原因中的任何一个而尚不可用。我们可能会从电源故障中恢复，并且 NFS 服务器比客户端慢。由于客户不知道的问题，网络可能会暂时关闭。 AWS 可能首先实例化了 NFS 客户端。
作为管理员，我们不想手动执行可以描述为“稍后重试”的任务。计算机知道如何稍后重试。
我们将 NFS 故障视为首要概念，方法是使用Restart不断重试挂载的选项，直到挂载最终成功。
任何需要等待 NFS 可用的操作都可以要求此服务作为依赖项。

[root@adele ~]# cat /etc/systemd/system/srv-music.service 
[Unit]
Description=Media devices
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/mount -t nfs4 -o vers=4,minorversion=1,owner,ro darknight.localdomain6:/Media /srv/music
ExecStop=/usr/bin/umount /srv/music
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Answer

我发现有效的方法是创建一个专用的 systemd 服务来完成挂载磁盘的工作，并忽略 systemd 的挂载功能。

这种方法的基础是：

NFS 可能由于一千个不同的原因中的任何一个而尚不可用。我们可能会从电源故障中恢复，并且 NFS 服务器比客户端慢。由于客户不知道的问题，网络可能会暂时关闭。 AWS 可能首先实例化了 NFS 客户端。
作为管理员，我们不想手动执行可以描述为“稍后重试”的任务。计算机知道如何稍后重试。
我们将 NFS 故障视为首要概念，方法是使用Restart不断重试挂载的选项，直到挂载最终成功。
任何需要等待 NFS 可用的操作都可以要求此服务作为依赖项。

[root@adele ~]# cat /etc/systemd/system/srv-music.service 
[Unit]
Description=Media devices
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/mount -t nfs4 -o vers=4,minorversion=1,owner,ro darknight.localdomain6:/Media /srv/music
ExecStop=/usr/bin/umount /srv/music
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

systemd：无法挂载 NFS 共享：mount.nfs：网络在启动过程稍后之前无法访问

答案1

答案2

答案3

答案4

相关内容