NFS v4 伺服器導致文件句柄陳舊，但僅當綁定掛載是子目錄時

在這一點上，這個問題基本上讓我發瘋了。我有一個 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)

到目前為止，使用這些客戶端 /etc/fstab 條目，在使用此配置的一個 nfs 客戶端上，這一切都執行良好：

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 上，儘管我無法想像這很重要。

我在這上面花了幾個小時，幾乎讓Google崩潰，尋找無濟於事的解決方案。

請注意，我只導出綁定掛載的文件系統。導出手冊頁中的這一部分是相關的：

fsid = 數字 | 根 | 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 來導出綁定掛載的文件系統。

引用自：https://serverfault.com/questions/898725