使用 NFSv4 fsid=0 並將 NFS 根導出到整個 LAN（或不導出）的影響
在 NFSv4 的教程中，通常會看到將共享根目錄導出到整個子網的建議，類似於Arch wiki：
/etc/出口：
/srv/nfs 192.168.1.0/24(rw,sync,crossmnt,fsid=0,no_subtree_check) /srv/nfs/music 192.168.1.0/24(rw,sync,no_subtree_check) /srv/nfs/public 192.168.1.0/24(ro,all_squash,insecure,no_subtree_check) desktop(rw,sync,all_squash,anonuid=99,anongid=99,no_subtree_check)根本沒有第一行會更安全嗎？（在我的問題中，當我提到“第一行”時，我指的是上面片段中的第一行導出。）
對於 NFSv4，fsid=0 是可選的，而且縮短路徑似乎主要是為了方便（通過將 /srv/nfs 轉換為 /）。在我的初步測試中，只要您使用 /srv/nfs，導出就可以在沒有第一行的情況下正常工作。第一行提供了哪些重要功能（如果有的話）？
當我們知道至少還有一個綁定掛載時，我還想考慮這個範例，例如：
/srv/nfs/projects（假設“項目”的內容是敏感的，不像音樂綁定掛載。）
正如上面所寫的，第一行導出似乎讓 LAN 上的每個客戶端都可以訪問整個導出的文件系統，尤其是使用 crossmnt 和 no_subtree_check。我並不是建議忽略所有者和組權限，但我認為如果沒有第一行並且其他綁定掛載在 /srv/nfs 下（例如 /srv/nfs/projects），導出也可以正常工作不會不必要地向整個子網開放，從而暴露出任何圍繞所有者和組權限的潛在疏忽。
當然，可以添加一個類似於此正確共享“項目”的導出：
/etc/出口：
/srv/nfs/projects 192.168.1.123(rw,sync,root_squash,subtree_check)這條新線路是否受到第一條線路的任何影響？我看不出第一條出口線是如何起到任何重要作用的。
如果這條線有幫助或推薦，那麼做這樣的事情是否明智？
/srv/nfs 192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash)接下來的更具體的導出將覆蓋這個是否正確？例如，即使第一行更改為 ro 並像下面的範例中那樣限制性更強，以下行是否會正確授予 rw 對“音樂”的訪問權限？
/srv/nfs 192.168.1.0/24(ro,sync,fsid=0,subtree_check,all_squash) /srv/nfs/music 192.168.1.2(rw,sync,no_subtree_check)訂單在列出出口時是否重要？什麼決定了優先級？更具體的地址（例如 192.168.1.2）是否會覆蓋更一般的地址（192.168.1.0/24）？
注意：這個問題只有一個重點主題，它可能會使用更好的標題來說明這一點，但到目前為止我還沒有想出正確的標題。我歡迎編輯。
導出的手冊頁說明了
fsid參數NFS 需要能夠辨識它導出的每個文件系統。通常它會使用文件系統的 UUID（如果文件系統有這樣的東西）或持有文件系統的設備的設備號（如果文件系統儲存在設備上）。
由於並非所有文件系統都儲存在設備上，而且並非所有文件系統都有 UUID，因此有時需要明確告訴 NFS 如何辨識文件系統。這是通過
fsid=選項完成的。現在我們知道為什麼
fsid有時需要該參數，讓我們看看手冊頁中關於 NFSv4 的說明（這部分與舊版本有很大不同）：對於 NFSv4，有一個可區分的文件系統，它是所有導出文件系統的根。這是指定的
fsid=root或fsid=0兩者都表示完全相同的事情。因此，換句話說，使用 NFSv4 範例中的第一行是定義一個基點，伺服器導出到某個客戶端的所有目錄都位於該基點下。乍一看，與 NFSv3 的靈活性相比，這聽起來像是退了一步，NFSv3 允許您導出任何目錄。但是，您可以輕鬆地將已安裝在其他位置的目錄帶入此目錄。只需添加如下一行
/etc/fstab/path/to/music/dir /srv/nfs/music none rbind 0 0並執行
mount -a以掛載新的文件系統。新方法本質上充當偽根文件系統，防止客戶端訪問此目錄之外的數據，從而允許 NFS 伺服器輕鬆檢查是否應授予客戶端訪問文件的權限，從而降低複雜性，同時提高安全性。