安裝 NFS 的 /var/spool/mail 用於 dovecot 和 procmail 的權限問題
我的郵件伺服器設置工作了多年。最近我開始遇到以下問題：
郵件設置：sendmail+dovecot+procmail
主機文件伺服器：CentOS 6.8，NFS 將郵件目錄導出到…
郵件伺服器：CentOS 7.3，通過 libvirtd/qemu 作為來賓 VM 在主機上執行，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 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain -r-------- 1 個普通使用者郵件 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain -r-------- 1 個普通使用者郵件 1 Mar 29 12:31 _uZF,kF-2YB.mailserver.domain -r-------- 1 個普通使用者郵件 1 Mar 29 12:31 _uZF.kF-2YB.mailserver.domain -r-------- 1 個普通使用者郵件 1 Mar 29 12:31 _uZF+kF-2YB.mailserver.domain
- 不會消失的鎖文件。典型的郵件日誌條目：
3 月 29 日 12:31:01 mailserver dovecot: imap(normaluser): Error: unlink(/var/spool/mail/normaluser.lock) failed: Operation not allowed 3 月 29 日 12:31:01 mailserver dovecot: imap(normaluser): 錯誤: file_dotlock_create() failed with mbox file /var/spool/mail/normaluser: Operation not allowed對於使用者而言，不會消失的鎖定文件意味著他們所有的郵件處理都會停止，直到我手動刪除鎖定文件。權限看起來很正常：
-rw------- 1 normaluser theirgroup 33 Mar 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 導入的目錄中執行任何操作。我嘗試向 NFS 伺服器添加一個 dovenull 帳戶（具有相同的 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我很近……我能感覺到……
再後來：
我能感覺到我想要的一切，但這並不意味著我有答案。我得到了能夠在 /var/spool/mail 中創建和刪除的 dovenull 帳戶（這與仔細查看 /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 等）創建文件，並且即使使用相同的權限進行刪除呼叫，刪除也不成功。
那麼什麼可能導致文件被創建，但無法被刪除呢？
我設法解決了這個問題，儘管它揭示了另一個（不太重要的）問題。
線索是偶爾，當我在 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 上發布這個問題。
之後：
一個快速的網路搜尋給了我這個：Partially wrong uid mapping with nfs4/idmapd/ldap-auth
在核心 3.13 中進行了修復，但目前的 CentOS7 是核心 3.10。我不知道 Redhat 是否已將修復程序反向移植到他們目前的 CentOS7 核心中。
這為我提供了導致問題的線索：我不斷地將新的活躍使用者添加到我們的集群環境中。在某些時候，我一定是在 /var/spool/mail 中觸發了 idmapd 錯誤的使用者數量。