☰

当尝试使用 sec=krb5 挂载 nfs4 共享时，我在 nfs 服务器上收到“未导出”错误消息

tag-icon • tag-icon kerberos nfs4
当尝试使用 sec=krb5 挂载 nfs4 共享时，我在 nfs 服务器上收到“未导出”错误消息

我运行两台 nfs 服务器，上面有用户主目录和其他共享。这些服务器提供基于 Kerberos 的 nfsv4 挂载以及旧版 v3 挂载。

直到最近，我才能够将一台服务器上的 krb5 导出共享通过 nfs4 挂载到另一台服务器上，没有任何问题。如果我现在尝试，则会收到权限被拒绝的提示，并且在 nfs 服务器日志中，我总是会看到如下所示的错误。nfs 服务器上带有用户数据的文件系统位于主机 server1.uni-ko.de 上的 /export/user1 和主机 server2.uni-ko.de 上的 /export/user2（主机名已更改）。路径 /export/ 用作由 fsid=0 标记的通用 nfs4 导出根目录。

## run on host server1.uni-ko.de
# mount -t nfs4 -o sec=krb5 server2.uni-ko.de:/user2 /mnt
mount.nfs4: access denied by server while mounting server2.uni-ko.de:/user2

在 nfs 服务器日志中我看到这个错误：

refused mount request from server1.uni-ko.de for /user2 (/): not exported

如果我尝试通过 nfs4 在同一主机上本地安装共享，也会发生同样的情况，如下所示：

## on host server1.uni-ko.de
# mount -t nfs4 -o sec=krb5 server1.uni-ko.de:/user1 /mnt
mount.nfs4: access denied by server while mounting server1.uni-ko.de:/user1

可以毫无问题地进行 nfs3 挂载（mount server1.uni-ko.de:/export/user1 /mnt）。

主机 server2.uni-ko.de 上的 /etc/exports 文件如下所示：

/export gss/krb5(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \
       gss/krb5i(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt) \
       gss/krb5p(rw,fsid=0,nohide,no_subtree_check,no_root_squash,async,crossmnt)
# NFS V3 exports via NIS netgroups
/export/user2   @nfsv3client(rw,async,no_subtree_check,no_subtree_check,fsid=2000)

exportfs -v 显示共享（krb5-nfs4）已导出：

# exportfs -v
....
/export         gss/krb5(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export         gss/krb5i(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export         gss/krb5p(rw,async,wdelay,nohide,crossmnt,no_subtree_check,fsid=0,sec=sys,secure,no_root_squash,no_all_squash)
/export/user2   @nfsv3client(rw,async,wdelay,hide,no_subtree_check,fsid=2000,sec=sys,secure,root_squash,no_all_squash)

事情变得更加奇怪，因为从默认的 nfs4 客户端，我仍然能够以 nfs4 方式挂载给定的目录，而不会出现任何问题，正如上面所述，并且两个系统共享相同的操作系统，相同的版本和补丁级别，即安装了最新补丁的 SuSE SLES15SP3。

在 nfs 服务器上，防火墙正在运行，打开 NFS 所需的静态分配端口，如 mountd、statd、lockd 以及端口 111 和 2049（所有端口都为 tcp 和 udp 打开）。这是我最近更改的。在此更改之前，nfs 服务器端口不是静态的，而是默认设置的，但我看不出这如何导致所描述的奇怪的挂载行为。我还完全禁用了防火墙，并再次测试，结果相同。

在后台，有一个 kerberos 服务器在运行，保存所有需要的主体。对于 nfs 服务器和所有 nfs4 客户端，有可用的“nfs”和“host”主体，并且每个服务器和客户端都有一个 /etc/krb5.keytab，其中包含此主机的导出“nfs”和“host”主体。当然，用户主体也存储在 kerberos 服务器中。除了所述新问题外，这一切都运行多年，现在仍然完美无缺。

答案1

问题似乎解决了。我最初没想到的解决方案分为两步：

  1. 我用的是rpc调试-命令调试 nfs rpc 调用，发现错误“(/): not explained”是由于主机尝试 NFS4 挂载共享失败（原因不明）然后切换到 NFS3 挂载，这也失败了，因为为 NFS4 提供的挂载路径不包含 NFS4 公共根 fsid=0 文件系统的路径（在我的情况下为 /export）。因此，实际上 nfs4 失败了，没有任何可见错误，nfs3 挂载失败并显示正确的错误消息。所以很明显 NFS4 是罪魁祸首，我可以忘记“not explained”错误消息了。

  2. 经过一番研究，我仔细查看了我们的 Kerberos 服务器，发现它最近进行了安全更新，并发布了新版本 (1.19.2)。我阅读了 MIT 文档 (https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html) 介绍了版本升级后应采取的步骤。其中一部分是更新几个可能旧的基于 DES 的内部密钥（DES 已弃用，很快就会被淘汰）。我在我们的 kerberos 服务器上有一个这样的密钥，名为：kadmin/历史。我按照文档说明更新了此密钥管理员过了一会儿，我发现 NFS4 安装问题已经消失。但是，我从未在 kerberos 服务器或 NFS 服务器或客户端上看到任何有关 kerberos 密钥问题的错误/警告消息。所以我看到 nfs4 安装又可以正常工作了，但我仍然有点怀疑这是否真的只是 kerberos des-key 导致了这个问题……

相关内容