☰

mount.nfs：挂载时服务器拒绝访问，导致 NFSv4 访问被拒绝错误

tag-icon • tag-icon linux nfs mount
mount.nfs：挂载时服务器拒绝访问，导致 NFSv4 访问被拒绝错误

这很奇怪，我已经没地方看了。欢迎任何建议。

同一VLAN内涉及三台主机，具体如下：

  • trillian (192.168.1.3/24)-虚拟机运行 Alma Linux 9.3，大约一个月前安装为 9.2 并升级。这是一台 NFS 服务器和 DNS 服务器。它无法访问自己的 NFS 共享。它取代了没有这个问题的旧版 trillian（CentOS Stream 8）。
  • marvin (192.168.1.2/24)-身体的运行 CentOS Stream 8，在 libvirt/QEMU/KVM 下运行两个虚拟机，并为虚拟机提供桥接网络。这可以访问trillian
  • agrajag (192.168.1.126/24)-虚拟机运行 AlmaLinux 9.3（今天构建）。不能访问 NFS 共享trillian。

还有几个其他物理和虚拟的 Fedora 39，它们在访问 NFS 共享时都没有问题。

NFS 服务器配置与默认配置相比没有变化，除了/etc/exports具有以下条目：

/srv/shares/steve localhost(rw) trillian.purplehayes.uk(rw) marvin.purplehayes.uk(rw) jabberwock.purplehayes.uk(rw) jubjub.purplehayes.uk(rw) dormouse.purplehayes.uk(rw) agrajag.purplehayes.uk(rw) arthur.purplehayes.uk(rw) alice.purplehayes.uk(ro) tweedledum.purplehayes.uk(ro) tweedledee.purplehayes.uk(ro)

fstab 条目如下所示：

trillian:/srv/shares/steve /mnt/nfs/steve nfs defaults 0 0

问题是两个 Alma Linux 9.3（其中一个是 NFS 服务器）无法挂载导出：它总是失败mount.nfs: access denied by server while mounting trillian:/srv/shares/steve

wireshark 跟踪显示，NFSv4 中 LOOKUP/GETATTR/ACCESS 序列与 相同，然后/srv是/srv/shares，最后是srv/shares/steve。失败发生在对第三个 ACCESS 命令的响应中：它应该返回0x1df，但它返回0x000，即所有访问均被拒绝。

Wireshark 解剖的差异显示了导致错误的差异：这是两次捕获中的两个数据包，第一个是好的，第二个是坏的。

2c2
<     167 15:49:52.104792256 marvin.purplehayes.uk 731    trillian.purplehayes.uk 2049        NFS      278    V4 Call (Reply In 168) ACCESS FH: 0xfb898914, [Check: RD LU MD XT DL XAR XAW XAL]
---
>     114 12:27:07.730078275 agrajag.purplehayes.uk 805    trillian.purplehayes.uk 2049        NFS      266    V4 Call (Reply In 115) ACCESS FH: 0xfb898914, [Check: RD LU MD XT DL XAR XAW XAL]
4,8c4,8
< Frame 167: 278 bytes on wire (2224 bits), 278 bytes captured (2224 bits) on interface br1, id 0
< Ethernet II, Src: 54:52:00:01:02:01 (54:52:00:01:02:01), Dst: RealtekU_01:03:00 (52:54:00:01:03:00)
< Internet Protocol Version 4, Src: marvin.purplehayes.uk (192.168.1.2), Dst: trillian.purplehayes.uk (192.168.1.3)
< Transmission Control Protocol, Src Port: 731, Dst Port: 2049, Seq: 7137, Ack: 7057, Len: 212
< Remote Procedure Call, Type:Call XID:0x791d8bd7
---
> Frame 114: 266 bytes on wire (2128 bits), 266 bytes captured (2128 bits) on interface br1, id 0
> Ethernet II, Src: RealtekU_01:7e:00 (52:54:00:01:7e:00), Dst: RealtekU_01:03:00 (52:54:00:01:03:00)
> Internet Protocol Version 4, Src: agrajag.purplehayes.uk (192.168.1.126), Dst: trillian.purplehayes.uk (192.168.1.3)
> Transmission Control Protocol, Src Port: 805, Dst Port: 2049, Seq: 6510, Ack: 6937, Len: 200
> Remote Procedure Call, Type:Call XID:0x99b4e2d3
16,17c16,17
<             sessionid: 5d386f652160d94b0700000000000000
<             seqid: 0x00000023
---
>             sessionid: 06ee6e65c8a3011bac00000000000000
>             seqid: 0x00000242
46c46
<     168 15:49:52.104911178 trillian.purplehayes.uk 2049   marvin.purplehayes.uk 731         NFS      238    V4 Reply (Call In 167) ACCESS, [Allowed: RD LU MD XT DL XAR XAW XAL]
---
>     115 12:27:07.730147846 trillian.purplehayes.uk 2049   agrajag.purplehayes.uk 805         NFS      238    V4 Reply (Call In 114) ACCESS, [Access Denied: RD LU MD XT DL XAR XAW XAL]
48,53c48,52
< Packet comments
< Frame 168: 238 bytes on wire (1904 bits), 238 bytes captured (1904 bits) on interface br1, id 0
< Ethernet II, Src: RealtekU_01:03:00 (52:54:00:01:03:00), Dst: 54:52:00:01:02:01 (54:52:00:01:02:01)
< Internet Protocol Version 4, Src: trillian.purplehayes.uk (192.168.1.3), Dst: marvin.purplehayes.uk (192.168.1.2)
< Transmission Control Protocol, Src Port: 2049, Dst Port: 731, Seq: 7057, Ack: 7349, Len: 172
< Remote Procedure Call, Type:Reply XID:0x791d8bd7
---
> Frame 115: 238 bytes on wire (1904 bits), 238 bytes captured (1904 bits) on interface br1, id 0
> Ethernet II, Src: RealtekU_01:03:00 (52:54:00:01:03:00), Dst: RealtekU_01:7e:00 (52:54:00:01:7e:00)
> Internet Protocol Version 4, Src: trillian.purplehayes.uk (192.168.1.3), Dst: agrajag.purplehayes.uk (192.168.1.126)
> Transmission Control Protocol, Src Port: 2049, Dst Port: 805, Seq: 6937, Ack: 6710, Len: 172
> Remote Procedure Call, Type:Reply XID:0x99b4e2d3
62,63c61,62
<             sessionid: 5d386f652160d94b0700000000000000
<             seqid: 0x00000023
---
>             sessionid: 06ee6e65c8a3011bac00000000000000
>             seqid: 0x00000242
70c69
<         Opcode: ACCESS (3), [Allowed: RD LU MD XT DL XAR XAW XAL]
---
>         Opcode: ACCESS (3), [Access Denied: RD LU MD XT DL XAR XAW XAL]
81,89c80,88
<             Access rights (of requested): 0x1df
<                 .... ...1 = 0x001 READ: allowed
<                 .... ..1. = 0x002 LOOKUP: allowed
<                 .... .1.. = 0x004 MODIFY: allowed
<                 .... 1... = 0x008 EXTEND: allowed
<                 ...1 .... = 0x010 DELETE: allowed
<                 .1.. .... = 0x040 XATTR READ: allowed
<                 1... .... = 0x080 XATTR WRITE: allowed
<                 .... .... = 0x100 XATTR LIST: allowed
---
>             Access rights (of requested): 0x00
>                 .... ...0 = 0x001 READ: *Access Denied*
>                 .... ..0. = 0x002 LOOKUP: *Access Denied*
>                 .... .0.. = 0x004 MODIFY: *Access Denied*
>                 .... 0... = 0x008 EXTEND: *Access Denied*
>                 ...0 .... = 0x010 DELETE: *Access Denied*
>                 .0.. .... = 0x040 XATTR READ: *Access Denied*
>                 0... .... = 0x080 XATTR WRITE: *Access Denied*
>                 .... .... = 0x100 XATTR LIST: *Access Denied*
94c93
<                     changeid: 835
---
>                     changeid: 7305793694093118725
99,100c98,99
<                     seconds: 1701785659
<                     nseconds: 338989372
---
>                     seconds: 1701012648
>                     nseconds: 850758917
102,103c101,102
<                     seconds: 1701785659
<                     nseconds: 338989372
---
>                     seconds: 1701012648
>                     nseconds: 850758917

这看起来确实像是服务器端错误，尽管这个问题只发生在客户端是 Alma Linux 9 的情况下（据我所知）更新：我将 agrajag 重建为 Alma Linux 8.9，但它仍然无法挂载共享。在服务器和rpcdebug -m rpc -c all客户端上使用各种方式，通过 systemd journal 或 dmesg 均未显示任何类似此错误的信息。我尝试过等，但似乎没有任何作用（我猜是因为这是在 systemd 下）。rpcdebug -m nfsd -c allrpcdebug -m nfs -c allsysctl -w sunrpc.nfsd_debug=1023

这不是：

  • 防火墙规则：NFS 流量正在流动
  • 网络相关：它发生在服务器上从本地主机安装
  • NFSinsecure选项：使用的端口小于 1024，并且没有 NAT
  • /etc/exports:的问题showmount -e给出了预期的结果
  • 问题/etc/hosts：所有名称解析均通过 DNS 进行（trillian 既是 DNS 服务器，也是 NFS 服务器；所有四台主机均具有正确的正向和反向条目）
  • selinux：禁用它不会改变任何东西
  • UID 和 GID 不匹配：所有挂载均在 下完成root(0:0)；文件访问由 完成steve(1000:1000)，并且导出仅由 root 压缩。
  • NFSv4：如果我尝试通过指定 进行挂载-o nfsvers=3，挂载可以成功，但尝试挂载ls文件会立即失败。由于 NFSv3 和 v4 有很大不同，这并不奇怪，但两者都会失败，客户端会报告相同的错误。
  • 那个特定的共享：我在另一个共享上也得到了同样的结果。

更新：

  • 我建立了一个新服务器arthur (192.168.1.127)-虚拟机运行 Alma Linux 8.9，它在其他方面是 trillian 的复制品。它显示相同的行为（和相同的 NFSv4 ACCESS 回复数据包），因此该问题特定于 EL 9.x 或特定版本。

答案1

您可以尝试在客户端上设置 NFS 服务器的 NFS 4 版本。如果您的 EL 8 提供 4.1 版本，请在 nfs 客户端的 fstab 中写入 vers=4.1。

nfsserver:/path/to/share /mnt/share nfs defaults,vers=4.1 0 0

答案2

显然，我还没有真正找到可以查看的地方！一些错误消息（我实际上并没有阅读！）说ls: cannot open directory '/mnt/nfs/steve': Permission denied。我还在 Wireshark 中只查看了 NFS，而不是 RPC。RPC 显示访问权限为0x000，UID=0,GID=0这是正确的：问题是读取UID=1000,GID=1000从未到达 NFS 服务器，因为它们在客户端被阻止，因为每个通向挂载点的目录的权限都不0700是0755。

这是因为它们都是使用 Ansibleansible.posix.mount任务创建的，循环遍历包含如下条目的字典列表（在 Ansible 清单中定义）：

        - path: /mnt/nfs/steve
          src: trillian:/srv/shares/steve
          fstype: nfs
          mode: '0700'

mode: 0700应该是mode: 0755。最近在重新整理库存时，我犯了两个剪切粘贴mode: 0700错误两个都我用于测试的挂载点的条目。

咕噜，咕噜，咕噜……

“我们对给您带来的不便深表歉意”

- 道格拉斯·亚当斯，再见，感谢所有的鱼

相关内容