☰

NFSv4 fsid 選項和導出根的目的

tag-icon • tag-icon nfs4
NFSv4 fsid 選項和導出根的目的

我的檔案伺服器只有一個大分區，在 /exports 下共享內容。因此，使用舊式 NFSv3 導出：

/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

於是我決定改用NFSv4風格，改成：

/exports          192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home     192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root     192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc              192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.

然後我更改了安裝命令以排除/exports.果然/etc是無法掛載的（雖然沒有報錯，只是鎖定直到中斷）。然而，正如我所料，/exports的 ACL 仍然向下繼承，所有共享都是唯讀的，root 到處都被壓扁了。

我還嘗試將 ACL 更改為/exports/root單一機器，但沒有什麼區別。

因此，除了能夠為那些無法確定識別碼的檔案系統提供唯一識別碼之外，定義導出根的意義何在fsid=0：

  • 這樣做會降低共享設定方式的靈活性（即繼承問題，除非在不同的檔案系統上並且您使用nocrossmount？）。
  • 假設舊式 NFSv3 設置，您仍然無法掛載，/etc那麼它提供了什麼額外的安全性？

只有當只是單獨檔案系統的安裝區域（安裝在其中並使用不同的 acl 匯出時）才有fsid=0意義嗎？/exports

在我看來，NFS 伺服器的設定已經被翻轉了。早在 Solaris 上，您就可以將所有共享內容直接安裝在下面/export並共享出去。伺服器將/home/user綁定安裝到/export/home/user.但現在/home是真正的檔案系統安裝位置，並且是綁定安裝在/exports.

它是否正確？

請注意：以上範例僅用於說明目的，因此請不要評論不使用的明智之舉no_squash_root，我知道。

非常感謝。

答案1

這是 NFS「掛載」協定工作方式的架構變化。

在 NFSv2/v3 中，有一個完全獨立的「MOUNT」RPC 協議，該協議允許客戶端透過其路徑取得任何匯出檔案系統的檔案句柄。但在隨後的 WebNFS 以及後來的 NFSv4 中，安裝更改為帶內 NFS 操作，同時該操作更改為返回單個「根」文件句柄，所有路徑查找都從該文件句柄下降。 （實際上 WebNFS 有兩個這樣的根，另一個是 nfs:// URL 的「公共」根，它沒有進入 NFSv4。）

因此，為了使“PUTROOTFH”操作起作用，必須是某種根檔案系統，因為不可能再跳過這些步驟 - 所有路徑遍歷都是一系列 [PUTROOTFH、LOOKUP、LOOKUP、...、LOOKUP、OPEN] 複合操作。這反映了 Plan9 的 9p 以及 SMBv2/3。

（所有這些都意味著在這種風格中，導出的檔案系統路徑變得相對於根目錄，例如您的 /exports/home 被安裝為“foo:/home”，不是如“foo:/exports/home”。

缺少 MOUNT(path) 操作也是隱含「crossmnt」的原因不是剩下的任何東西都可以掛載，這一切都只是從根目錄向下「找到」。

實際上，NFSv4 可以使用任一樣式 – 如果未定義「fsid=0」匯出，則 Linux 核心（2.6.33 或更高版本）會自動/為你產生一個虛擬根除了常規匯出位置的安裝座之外，不包含任何內容。 （這也具有在 NFSv3 和 NFSv4 之間保留相同安裝路徑的優點。）換句話說，您確實可以繼續使用原始 v3 樣式的配置。

相關內容