NFS 伺服器重新啟動後的 NFS 陳舊文件句柄：為什麼會發生這種情況以及行業如何處理這種情況？
這個問題一直讓我發瘋。
我有一個 NFS 伺服器，其 NFS 共享安裝在各種客戶端上。但是，每當我必須重新啟動 NFS 伺服器時，我總是會在所有客戶端的掛載上遇到一堆“陳舊文件句柄”錯誤，這迫使我必須手動解除安裝並重新掛載客戶端上的 NFS 共享。
我已經在我的 NFS 伺服器上檢查了我的導出，
cat /etc/exports並且我在重新啟動時為每個 NFS 導出傳遞了相同的 fsid。我的問題：
- 工業界如何處理這個問題？我很難想像系統管理員會進入並手動解除安裝/重新安裝每個客戶端或簡單地重新啟動連接的客戶端。還是真的是這樣處理的？（除了標準，“我們永遠不會停機，我們永遠不必重新啟動 NFS 伺服器。”）
- 為什麼會這樣？這是因為即使 fsid 可能相同，NFS 伺服器也會重新計算文件句柄，而這些文件句柄在重新啟動時可能不一樣？
- 在我的掛載配置中我應該做些什麼來防止這種情況發生嗎？
/etc/fstab:[NFSserver]:/mnt/backup /mnt/backup nfs bg,nfsvers=3,tcp 0 0根據這篇文章，建議添加
hard和intr安裝選項，但這似乎沒有任何區別。
- 如果所有其他方法都失敗了，我是否應該回退到使用 bash 腳本來監視掛載/目錄是否存在陳舊文件錯誤並讓它執行解除安裝/掛載週期？
提前致謝。
-扭矩扳手
您正在使用 NFS 版本 3，除了埠 2049 中的主要 NFS 服務之外，它還需要幾個輔助服務。其中之一是
rpc.statd，它在檢測重新啟動和重新啟動後恢復/清除 NFS 鎖定方面起著關鍵作用。這些輔助服務可能位於隨機埠中，它們是通過聯繫 RPC 埠映射器（通常是
rpcbind現代 Linux 上命名的程序）來發現的。在具有防火牆的現代網路中，這種行為可能會使事情變得困難：即使您在重新啟動後可能會在具有確定性外觀的埠中找到它們，但如果/當您重新啟動 NFS 服務時，它們可能會被分配到完全不同的埠號。幸運的是，在許多現代類 Unix 系統上，您可以鎖定 NFS 鎖定管理器的埠號（過去
rpc.lockd，現在通常在核心中實現），rpc.statd並且rpc.mountd. 如果您想通過具有任何可靠性的防火牆通過 NFSv3，這是必不可少的。對於 RHEL 和相關發行版，您可以通過在以下程式碼中添加以下行來鎖定 NFS 幫助程序端口號
/etc/sysconfig/network：LOCKD_TCPPORT=4045 LOCKD_UDPPORT=4045 STATD_PORT=4046 MOUNTD_PORT=4047對於 Debian 和相關發行版，您可以將此行添加到
/etc/modprobe.d/nfs.conf：options lockd nlm_udpport=4045 nlm_tcpport=4045…而這一行在
/etc/default/nfs-common：STATDOPTS="-p 4046"…而這一行在
/etc/default/nfs-kernel-server：RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here（如果您願意，您可以使用不同的埠號，但 4045 是 Solaris 中 NFSv3 鎖管理器的預設埠，並且在 HP-UX 11.31 中是硬編碼的。）
但是 NFSv3 協議中還有另一個陷阱。儘管您可以僅使用 IP 地址成功掛載 NFS 共享，但 NFSv3 鎖定協議在內部使用主機名。客戶端和伺服器都必須通過正確的名稱相互認識，否則重啟後的 NFS 文件鎖定和鎖定恢復將不起作用。每個系統的“正確名稱”是由
uname -n.因此，如果在伺服器和客戶端分別
uname -n返回，那麼您應該確保這些確切的名稱將解析為主機需要用於 NFS 的 IP 地址。換句話說，伺服器必須能夠使用該名稱聯繫客戶端，反之亦然。server.example``client.example``rpc.statd``client.example如果您不這樣做，起初一切似乎都執行良好……但是當任一端重新啟動時，您可能會遇到這些
Stale file handle錯誤。