在這一點上，這個問題基本上讓我發瘋。我有一個 Ubuntu 16.04 NFS 伺服器，使用此配置可以正常工作：
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
和
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
到目前為止，在使用此配置的一個 nfs 用戶端上，使用這些客戶端 /etc/fstab 條目，這一切都運行良好幾個月：
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
然而，由於這是一個非常大的儲存伺服器，因此決定它需要容納多個實驗室。因此，我將分散在 /data2 分區中的所有內容移至 /data2/cryodata 子目錄中，並更新了伺服器上的 /etc/fstab 和 /etc/exports，如下所示：
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
和
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
這根本不行！當我嘗試使用相同的客戶端 /etc/fstab 條目在客戶端上安裝新安裝時：
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
。
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
/usr/local 繼續掛載，沒有任何問題。我第一次嘗試這個時，我確實忘記了exportfs -var在進行更改之前取消導出/導出使用的文件系統，但從那時起我就來回切換，小心地取消導出和卸載所有內容，其間有幾次伺服器重新啟動。整個分區的綁定掛載的原始掛載始終有效，而子目錄的綁定掛載每次都會失敗，並顯示陳舊的 nfs 句柄訊息。我嘗試啟用其他從未安裝過這些分割區的 nfs 用戶端，並獲得完全相同的錯誤訊息：在這種情況下，這肯定是伺服器端問題。我檢查了 /var/lib/nfs/etab 以確保它在安裝嘗試之間被清除，等等。
我認為綁定安裝到 nfs 伺服器根目錄的技術可以解決所有這些類型的問題，但顯然不是？奇怪的是 /usr/local 是另一個分割區的子目錄，而且它總是安裝得很好。它位於 ext3 md raid 1 上，儘管我無法想像這很重要。
我花了幾個小時在這上面，幾乎打破了谷歌尋找解決方案卻無濟於事。
答案1
請注意，我僅匯出綁定安裝的檔案系統。本節來自出口手冊頁相關：
fsid=num|根|uuid
NFS 需要能夠識別它導出的每個檔案系統。通常它會使用檔案系統的 UUID（如果檔案系統有這樣的東西）或保存檔案系統的裝置的裝置號碼（如果檔案系統儲存在裝置上）。
我的錯誤假設是綁定安裝的檔案系統有某種 NFS 可以自動使用的 UUID；這些綁定安裝的導出在沒有 fsid 的情況下也能正常運作，這一事實強化了這一假設：
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
然而，這會導致行為不一致。我新增了一個綁定安裝/opt：
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
導致行為不一致；即可以更改匯出 IP 並安裝在一台電腦上，但在另一台電腦上獲得拒絕許可。解決方案是添加一個 fsid：
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
因此，解決方案是始終添加一個 fsid 來匯出綁定安裝的檔案系統。