我的鬍子現在是純灰色的，我很清楚地記得這幾十年來一直使用 NFS，這裡我引用了原來的RFC這為我們今天的 NFS 奠定了基礎RFC1094。當然，三十年過去了，有些已經過去了，所以這是問題：
在過渡期現在可以透過設定選項從伺服器端解釋連結嗎？這肯定會解決我的一些客戶端連結解釋問題！
或者，我是否都濕透了，我引用的內容已經過時了，默認情況下，它實際上是在伺服器端解決的，而我只是在故障排除中在兔子洞裡追兔子？
如果它仍然是老式的和解釋的客戶端，並且如果沒有啟用伺服器端解釋的選項，那麼使用相對連結而不是絕對連結可能有幫助嗎？
謝謝。
答案1
符號連結始終由客戶端解析。這有幾個原因。首先，NFS協定有一個文件句柄的概念。每個句柄都指向一個檔案系統對象，該對象可以是目錄、檔案或符號連結（以及其他一些）。而且，NFSv4.1規範明確表示：
無論是由 NFS 用戶端創建還是在伺服器本地創建，符號連結中的資料在創建時都不會被解釋，而只是被儲存。
其次，透過在伺服器端處理符號鏈接，必須考慮額外的權限規則，因為符號連結可能指向導出的檔案系統的外部。
事實上，SAMBA 伺服器沒有遵循符號連結的選項。這是因為 (a) 原始 MS 檔案系統沒有符號連結的概念，(b) 增加了作為檔案系統物件類型的符號鏈接中小企業2。順便說一句，該行為符合 NFS 解釋：
伺服器不得評估符號連結。
如果需要，有幾個用戶空間 NFS 伺服器允許自訂檔案系統實作：
如果有一個好的原因是要在伺服器端解析符號鏈接，可以添加此內容。
答案2
我的網路上有兩台計算機，它們具有指向伺服器的相同 NFS 掛載設定。在伺服器上，存在從一個導出目錄到另一個導出目錄的符號連結。在一個客戶端上，連結運作正常，而在另一個客戶端上，連結則不可靠。我懷疑由於工作客戶端有新版本的 NFS（使用相同的協定），因此修復了一個錯誤。理論上，請求應該發送到伺服器並在那裡進行解釋，因為這就是進行匯出的原因。如果客戶端在資料夾中放置符號鏈接，那麼它可能會在其他客戶端上被破壞。但是，伺服器符號連結應該可以工作。這個一般表示需要一種特殊類型的網路共享符號連結。類似伺服器符號連結的東西。