所有机器都运行 CentOS 6.5。我们有大约 85 台客户端机器正在对服务器进行 Kerberized NFSv4 挂载（sec=krb5p）。这个周末，服务器发生了变化（服务器 A 更改为服务器 B）。
一切似乎都正常，除了， 在一一些客户端服务器仅有的，并且仅适用于一对于一些特殊用户来说，idmapd 似乎在大约 30 到 45 分钟后停止工作。
简单测试：在有问题的客户端机器上，我执行如下操作：
while [ 1 ]; do touch test.`date +%H%M%S`.txt ; sleep 1m ; done
然后观察文件创建的过程。它们一开始具有正确的用户和组 ID。但大约 35 分钟后，它们突然变为由 nfsnobody:nfsnobody 所有。
idmapd 进程仍在运行。其他用户和其他机器显然没有受到影响。（当然，我们没有测试所有用户和所有机器，但对其他用户和其他机器进行抽样测试没有发现任何问题。）
编辑：忘记发布一些重要细节：
- 最初，新的 NFS 服务器没有正确的 /etc/idmapd.conf。它使用的是默认设置。该问题现已得到纠正，并且服务器和客户端上的 idmapd 服务均已重新启动。
客户端和服务器上的 /etc/idmapd.conf 文件相同。- 客户端和服务器上的 /etc/passwd 和 /etc/group 文件相同。
编辑2：经过进一步审查，我们观察到以下情况：
- 服务器上的 /etc/idmapd.conf 与客户端不同，它还具有一些静态映射。这些静态映射适用于需要从 Kerberized NFSv4 共享运行 cronjobs 的少数关键用户。 此链接准确描述服务器 /etc/idmapd.conf 文件上特殊配置的类型。
- 问题实际上会时有时无（不会简单地变坏并一直很糟糕）。在我上面的示例“触摸”测试中，文件会在一段时间内以正确的用户和组所有权创建。然后在大约 45 分钟后，它们会开始以 nfsnobody 所有权创建。然后一段时间后，它们会以正确的所有权创建。断断续续，没有明显的模式。
- 这仅发生在具有上述“特殊” /etc/idmapd.conf 映射的用户身上，并且仅发生在这些用户具有 cron 作业的机器上。
答案1
冒着给自己带来厄运的风险，看来重新启动 NFSv4 服务器可以解决这个问题。重新启动后已经过去了大约三个小时，到目前为止还没有出现任何问题。以前，我们从来没有超过一个小时没有至少一个帐户进入上述糟糕的“状态”。
我无法真正解释这一点，只能猜测服务器上有一些剩余的“垃圾”，当使用正确的配置重新启动 rpc.idmapd 服务器时，这些垃圾没有被清除。