☰

SLES 10.2 中网络服务启动失败，可能导致 NFS 客户端问题

tag-icon • tag-icon networking nfs sles10
SLES 10.2 中网络服务启动失败，可能导致 NFS 客户端问题

在最近从 SLES 9.3 升级到 10.2 的机器上，我发现了以下问题：

升级之前，NFS 挂载（通过 yast 定义，即 中出现/etc/fstab）工作正常。但升级后，它失败了。网络跟踪显示它通过 TCP（用于端口映射器 RPC）与 NFS 服务器建立初始连接，但随后切换到 UDP 进行后续的 MOUNT 调用；由于 NFS 服务器不允许使用 UDP（有充分理由，因为可能存在数据损坏问题，如 中所示nfs(5)），因此连接将无法通过。

添加 TCP 选项（无论是在 fstab 中，还是在命令行等）都没有效果。

在对此进行故障排除的过程中，我发现 /var/adm/messages 报告启动期间发生以下情况：

Failed services in runlevel 3: network

（我应该指出，尽管出现了这个错误信息，但显然至少有一些网络服务已经启动，因为可以通过 SSH 访问该框。）

我的问题是：

  1. 我应该查看什么来确定服务启动失败的原因？
  2. 这确实有可能导致上面描述的 NFS 问题吗？
  3. 如果对 (2) 的回答是否定的，那么对于要寻找什么有什么建议吗？

编辑以添加一些与以下答案相关的信息。

事实证明，网络服务在启动时失败，因为其中一个接口（此框上有两个）使用 DHCP，而目前还不可用。所以我暂时禁用了它，停止/重新启动了网络服务和 NFS 客户端服务，但仍然得到相同的结果。

客户端没有防火墙。此外，客户端的 iptables -L 显示所有内容均被接受；并且 /etc/hosts.allow 或 /etc/hosts.deny 中没有任何条目。

在 NFS 服务器端，什么都没有改变。远程 nfsserver 确实在宣传它允许所有 NFS 服务使用 TCP 和 UDP（尽管有一条 iptables 规则阻止了 UDP）。

/etc/fstab 条目非常简单 - 您可以在 yast 中设置它：

x.x.x.x:/volume      /localdir   nfs     defaults 0 0

客户端的 rpcinfo -p 仅显示正在运行的 portmapper v2，同时通告 TCP 和 UDP。对于服务器，它显示所有常用服务：

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   4047  status
    100024    1   tcp   4047  status
    100011    1   udp   4049  rquotad
    100021    1   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100021    1   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr
    100005    1   udp   4046  mountd
    100005    1   tcp   4046  mountd
    100005    2   udp   4046  mountd
    100005    2   tcp   4046  mountd
    100005    3   udp   4046  mountd
    100005    3   tcp   4046  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

使用上面的 /etc/fstab 条目的 mount 调用非常简单：

mount /localdir

虽然我也尝试过各种选项，例如 tcp、v3 等等。

/etc/fstab 条目（因此挂载）和 rpcinfo -p 调用都使用 IP 地址，所以不涉及 DNS 解析问题。

答案1

检查以确保/etc/hosts.deny不包含 的条目mountd，并检查hosts.allow，原因类似。不管怎样，我通常会清除hosts.deny并使用iptables它以控制访问。

用来rpcinfo -p nfsserver确保mountd确实在宣传 TCP — 有一个选项-n可以禁用 TCP 监听，该选项（SuSE 上的 IIRC）可能会设置在/etc/sysconfig/nfs或其附近。

答案2

据我了解，您的问题可以执行以下操作：

  • ssh 到你的 nfs 客户端系统
  • rpcinfo从客户端到服务器的“连接”
  • 您已禁用 dhcp 接口，因此所有流量都通过一个接口，没有其他路由

但是您无法在 nfs 客户端上挂载来自 nfs 服务器的文件系统，并且没有收到任何错误消息。

rpcinfo您的和调用之间有什么区别mount？您是否在一个中使用 ip 地址，而在另一个中使用 fqdn？您能否发布带有输出和返回代码的两个命令？

答案3

有几件事。首先，您在开头声明了since the NFS server doesn't allow UDP，然后在编辑中提到了The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services。这似乎有点奇怪。为什么服务器会通告它不允许的内容？

其次，您是想使用 NFS 版本 2 还是版本 3？版本 2 仅支持 UDP，而 TCP 则需要版本 3。也许在挂载选项中手动指定版本 3 会有所帮助？（vers=3）如果默认为 2，那么即使指定 TCP 也无济于事。

当服务器不太支持版本 4 时，我也遇到过新客户端尝试使用版本 4 的问题。您的 SLES 升级可能导致不同的默认版本。更有理由明确指定它。

为什么你不把 /etc/fstab 中的条目也发布出来呢？

答案4

尝试明确设置并查看结果。例如，在 /etc/fstab 中：

x.x.x.x:/vol /local nfs proto=tcp,port=2049,mountport=4046,nfsvers=3 0 0

这至少应该绕过端口映射器并明确尝试连接到您上面列出的 TCP 端口，并使 tcpdump 在调试期间更容易跟踪每个通道。

相关内容