☰

无法挂载 nfs 共享。执行挂载命令时客户端和服务器之间没有流量

tag-icon • tag-icon nfs4 rhel8
无法挂载 nfs 共享。执行挂载命令时客户端和服务器之间没有流量

nfs 客户端和服务器都是 redhat enterprise linux。服务器之间没有防火墙。

nfs 服务器在 /etc/exports 中具有正确的共享和数据。所有服务均已启动并正在运行。portmap rpcbind、nfsd。尝试安装 nfs 共享时没有任何反应。我尝试使用 tcpdump 嗅探流量，并在从客户端执行时获取数据：

showmounts -e < nfs server> 
rpcinfo -p <nfs server>

这是 rpcinfo -p <nfs_server> 的输出

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  52430  status
    100024    1   tcp  37923  status
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  49706  nlockmgr
    100021    3   udp  49706  nlockmgr
    100021    4   udp  49706  nlockmgr
    100021    1   tcp  38046  nlockmgr
    100021    3   tcp  38046  nlockmgr
    100021    4   tcp  38046  nlockmgr

我可以在输出中看到份额showmount -e。

telnet 端口 111 和 2049 可以正常连接。

但尝试挂载时，网络没有任何反应，没有传输任何数据包

mount -t nfs  example:/share /app/shared -o _netdev,rw,async,vers=4 -vvvv

答案1

该问题是由于使用 lazy umount 引起的。

umount -l

一旦 NFS 共享被延迟卸载，就无法再次重新挂载相同的 NFS 共享，因为延迟卸载不会完全分离文件系统，因为一些现有的活动进程仍然持有

可以使用以下方法验证：

 cat proc/fs/nfsfs/servers
 NV SERVER   PORT USE HOSTNAME
 v4 ac1a4c0a  801  16 nfssrv.example.com.

这里我们可以看到 NFS 服务器有 16 个过期条目

解决挂载问题的唯一方法是重新启动 NFS 客户端，如手册页中所述：

-l, --lazy
              Lazy unmount.  Detach the filesystem from the file hierarchy now, and clean up all references to this filesystem as soon as it is not busy anymore.

              A system reboot would be expected in near future if you're going to use this option for network filesystem or local filesystem with submounts.  The recommended use-case for umount -l is to prevent hangs on  shut‐
              down due to an unreachable network share where a normal umount will hang due to a downed server or a network partition. Remounts of the share will not be possible.

相关内容