在虚拟机内部,主机地址为 10.0.2.2,本地地址为 10.0.2.15。(VirtualBox)。在主机端,该地址被转换为 127.0.0.1。要连接:
sudo mount -vvvt nfs4 -o clientaddr=127.0.0.1 10.0.2.2:/srv /mnt
我指定了 clientaddr,因为我认为问题可能是由于地址不匹配造成的,但这并没有改变任何东西。几分钟后,客户端返回通常的“权限被拒绝”消息,即服务器拒绝访问。
在服务器端,我运行
# rpc.mountd -d all -F
# rpc.idmapd -vvvf
# rpc.nfsd -d
我使用 systemd,因此我也在监控日志中的任何输出。当我发出挂载请求时,网络上可以看到以下内容:
reply ERR 20: Auth Bogus Credentials (seal broken)
但除了一些启动消息外,日志(应该包含 rpc.nfsd 的输出)或 rpc.mountd 或 rpc.idmapd 的输出中什么也没有出现。实际上,对于 rpc.mountd,我偶尔会收到以下信息:
rpc.mountd: auth_unix_ip: inbuf 'nfsd 127.0.0.1'
rpc.mountd: auth_unix_ip: client (nil) 'DEFAULT'
据我所知(请纠正我!)没有其他有关 NFS 功能的信息来源,也没有涉及任何配置。我已经为每个命令指定了详细模式,所以我不知道该如何诊断这个问题。
我假设这是我的导出文件的问题,如下所示:
/srv 127.0.0.1(rw,sync,no_subtree_check,no_root_squash)
但我宁愿从系统那里得到一些关于哪里出错的反馈,而不是通过反复试验来摆弄我的导出文件。所以,有人知道我可以在哪里找到有关正在发生的事情的更多信息吗?
谢谢!
编辑
我最近运行了 exportfs -rav
现在客户端立即返回“操作不允许”,并且 rpc.mountd 输出:
rpc.mountd: auth_unix_ip: inbuf 'nfsd 127.0.0.1'
rpc.mountd: v4root_create: path '/' flags 0x12401
rpc.mountd: v4root_create: path '/srv' flags 0x10401
rpc.mountd: auth_unix_ip: client 0x1d69d70 '127.0.0.1'
rpc.mountd: nfsd_fh: inbuf '127.0.0.1 1 \x00000000'
rpc.mountd: nfsd_fh: found 0x1d73e90 path /
但此输出可能仅与运行 exportfs 有关。(请注意,我之前多次重新启动守护进程,因此我不知道 exportfs 有何不同)
好的,看来添加“不安全”选项已经解决了这个问题:
secure This option requires that requests originate on an Internet port less than
IPPORT_RESERVED. (1024). This option is on by default. To turn it off, specify
insecure.
这很奇怪,因为我以 root 身份运行 NFS 客户端。
无论如何,为什么这个问题没有向操作员(我自己)公开?如果软件的诊断完全隐藏,以至于非专家无法访问,我不明白如何认为该软件适合生产使用。我并不是想在这里抨击 NFS,但它似乎是一个臭名昭著的混淆系统,考虑到它的使用频率,它确实需要更多的透明度。无论如何,感谢您的阅读。
答案1
可以尝试的一件事是测试完全开放的权限/etc/exports
(0.0.0.0/0 可能是正确的完全开放权限)。如果这有效,那么可能与 NFS 无法完全识别客户端请求来自何处有关,尽管我注意到您提到网络流量是经过 NAT 的。
答案2
这可能无法解决其他人的问题,但以下方法对我有用。更改服务器的主机名并重新启动后,我收到了“Auth Bogus Credential”的废话。
确保你执行了绑定挂载。对我来说,我的导出是 /srv/nfs4/foo,所以我执行了
sudo mount --bind /home/jay/foo /srv/nfs4/foo
清除 nfs etab 缓存并重新导出
导出文件系统-rav
就像变魔术一样,它又起作用了。我把这两件事写进脚本里,这样如果我再次需要它们,我就不用四处寻找和咒骂了。
#!/bin/bash
sudo mount --bind /home/jay/foo /srv/nfs4/foo
exportfs -rav