我的邮件服务器设置已经运行多年。最近我开始遇到以下问题：
邮件设置：sendmail+dovecot+procmail
主机文件服务器：CentOS 6.8，NFS 将邮件目录导出到……
邮件服务器：CentOS 7.3，通过 libvirtd/qemu 在主机上作为客户虚拟机运行，NFS 从主机挂载 /var/spool/mail。
症状：dovecot 和 procmail 都发出了错误（详情如下），似乎表明它们没有写入 /var/spool/mail 的权限。但是，/var/spool/mail 具有我所知道的最通用的权限，无论是在 NFS 文件服务器还是在邮件 NFS 客户端上。
在邮件服务器（NFS 客户端）上：
$ ls -lhd /var/spool/mail
drwxrwxrwt 5 root mail 6.8M Mar 29 12:37 /var/spool/mail
在邮件服务器：/etc/fstab 中：
filehost:/mail/inbox /var/spool/mail nfs defaults 0 0
在 NFS 主机上：
$ ls -lhd /mail/inbox
drwxrwxrwt. 5 root mail 6.8M Mar 29 12:41 /mail/inbox
在文件主机：/etc/exports 中：
/mail/inbox mailserver(rw,no_root_squash,async,nohide)
两个系统都没有运行 SELinux 或 iptables（我依赖于我们站点的防火墙）。
我看到的事情如下：
文件名类似于 BOGUS.normaluser.hex-string。相应的日志消息是
3 月 29 日 12:14:34 邮件服务器 procmail[20922]: 将虚假的“/var/spool/mail/normaluser.lock”重命名为“/var/spool/mail/BOGUS.normaluser.xGAs”
这可能特别烦人，因为有时不仅锁定文件被声明为假，而且普通用户的收件箱也被声明为假。从普通用户的角度来看，他们的收件箱在他们阅读邮件时消失了。
文件名称以下划线开头，例如，_2-E,eu92YB.mailserver.domain。
没有相应的日志消息。这些文件的内容（始终为 1 字节或 31-33 字节）表明这些是锁文件。我昨天看到的一个网页描述了有人使用 strace 来识别 procmail 正在写入这些文件，但我不知道如何使用 strace 来亲自确认这一点（今天我找不到该页面）。
当我列出文件时，我看到它们是 chmod 400，这可能是它们没有被删除的原因：
-r-------- 1 普通用户邮件 1 3 月 29 日 12:30 _uZF%kE-2YB.mailserver.domain -r-------- 1 普通用户邮件 1 3 月 29 日 12:30 _uZF+kE-2YB.mailserver.domain -r-------- 1 普通用户邮件 1 3 月 29 日 12:31 _uZF,kF-2YB.mailserver.domain -r-------- 1 普通用户邮件 1 3 月 29 日 12:31 _uZF.kF-2YB.mailserver.domain -r-------- 1 普通用户邮件 1 3 月 29 日 12:31 _uZF+kF-2YB.mailserver.domain
- 不会消失的锁文件。典型的邮件日志条目：
3 月 29 日 12:31:01 邮件服务器 dovecot：imap（normaluser）：错误：取消链接（/var/spool/mail/normaluser.lock）失败：操作不允许 3 月 29 日 12:31:01 邮件服务器 dovecot：imap（normaluser）：错误：file_dotlock_create（）因 mbox 文件 /var/spool/mail/normaluser 而失败：操作不允许
对于用户来说，锁文件不消失意味着他们的所有邮件处理都会停止，直到我手动删除锁文件。权限似乎正常：
-rw------- 1 普通用户 theirgroup 33 3 月 29 日 12:30 normaluser.lock
我根据 dovecot wiki 对 dovecot 选项进行了一些尝试，希望我犯了错误。当前相关值是：
mmap_disable = yes
dotlock_use_excl = yes
mail_fsync = optimized
mail_nfs_storage = no
mail_nfs_index = no
mail_privileged_group=mail
设置 mail_nfs_storage=yes 似乎不会改变任何东西，因为该参数（根据 dovecot wiki）与多个邮件服务器通过 NFS 访问同一目录有关，而这里并非如此。
我搜索了 Google 并摸索了好久，还是没能找到问题所在。我想问一下我忽略了什么，或者询问我可以运行的其他诊断程序的建议。
之后：
我离解决方案越来越近了。在客户端邮件服务器上：
$ cd /var/spool/mail
$ sudo -u normaluser touch test
$ sudo -u normaluser rm test
没问题。
$ sudo -u dovenull touch test
$ sudo -u dovenull rm test
rm: cannot remove ‘test’: Operation not permitted
$ ls -lh test
-rw-r--r-- 1 nobody nobody 0 Mar 31 12:03 test
啊哈！dovenull 帐户不允许在 NFS 导入的目录中执行任何操作。我尝试将 dovenull 帐户添加到 NFS 服务器（具有相同的 uid/gid），但这并没有解决问题：
$ sudo -u dovenull rm test
rm: cannot remove ‘test’: Operation not permitted
$ ls -lh test
-rw-r--r-- 1 dovenull dovenull 0 Mar 31 12:03 test
这感觉像是 idmap 问题。以下是客户端和服务器上 idmap.conf 中唯一未注释的行：
[General]
Domain = mydomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch
我快到了……我能感觉到它……
后来：
我可以感受到我想要的一切，但这并不意味着我有答案。我让 dovenull 帐户能够在 /var/spool/mail 中创建和删除（这与仔细查看 /etc/nssswitch.conf 并意识到我必须重新启动 NIS 有关），但这并没有解决我的问题。dovenull 帐户不会写入 /var/spool/mail。
我使用了 auditctl：
auditctl -w /var/spool/mail -p war -k mail-inbox
ausearch -k mail-inbox > mail-inbox.txt
并验证了额外的 .lock 文件和 BOGUS 文件是由 dovecot 创建的，而“_”下划线文件是由 procmail 创建的。除非有人想看审计日志，否则我不会费心发布它们；它们显示的是文件是使用正确的权限（uid、gid、euid 等）创建的，并且删除操作失败，即使删除调用是使用这些权限进行的。
那么什么原因会导致文件被创建但无法被删除呢？
答案1
我设法解决了这个问题，但它暴露了另一个（不太重要的）问题。
线索是，偶尔，当我在 NFSv4 客户端上列出 /var/spool/mail 时，我会看到如下内容：
-r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain
-r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain
-rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser
然后当我立即执行“ls -lh”时，我会看到：
-r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain
-r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain
-rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser
该数字 4294967294 在 32 位无符号整数中为 -2，通常是分配给 nfsnobody 帐户的 UID。这向我暗示可能存在暂时的 idmapd 问题。这与我观察到的情况一致：有时邮件服务器会表现得好像它没有通过 NFS 的 rwx 权限，即使它刚刚创建了该文件。由于只有 NFSv4 使用 idmapd（至少对于 NFS 版本而言），我通过更改邮件服务器 NFS 客户端上的 /etc/fstab 中的一行切换到 NFSv3：
filehost:/mail/inbox /var/spool/mail nfs defaults,vers=3 0 0
然后我重启了邮件服务器，然后就好了！NFS 问题消失了。顺便说一下，我在诊断问题时重启了邮件服务器好几次，所以这是不是“通过简单重启即可解决”的情况。
当然，这引发了为什么 idmapd 有问题的问题。任何好奇的人都可以查看上面的 idmapd.conf 配置。但这是一个单独的问题，对我来说优先级要低得多。我可能会在某一天将这个问题发布在 serverfault 上。
之后：
通过快速的网络搜索，我得到了以下信息：nfs4/idmapd/ldap-auth 的 uid 映射部分不正确
内核 3.13 中实现了修复，但当前的 CentOS7 是内核 3.10。我不知道 Redhat 是否已将修复移植到其当前的 CentOS7 内核中。
这给了我问题原因的线索：我不断向我们的集群环境添加新的活跃用户。在某个时候，我肯定超出了 /var/spool/mail 中的用户数量，从而触发了 idmapd 错误。