當在 samba 共享上從一點到另一點（同一驅動器上）創建符號鏈接時，保存符號鏈接的文件在其他客戶端上會變得混亂，但在原始客戶端上不會。
例如，在進行連結的用戶端上，即使在重新掛載之後，符號連結也能完美運作並被原始作業系統識別：
lrwxrwxrwx 1 g g 38 Mar 17 11:15 npm2 -> ../lib/node_modules/npm/bin/npm-cli.js
但是，在伺服器或其他客戶端上，連結是一個內容如下的檔案：
XSym
0038
36c91a46c3a5a86837deff259c6d0874
../lib/node_modules/npm/bin/npm-cli.js
....具有權限：
-rwxrw-r-- 1 z z 1067 Mar 17 11:15 npm2
所以...基本上...這是某種安裝錯誤，或者其他什麼，但是有什麼方法可以使用 chmod 將其“meep”到原來的符號鏈接中嗎？這會有很大幫助。
答案1
不，您不能使用 chmod 來更改檔案的基本類型。但它是一個文件，並不是因為任何錯誤——它是一個文件，因為 Samba 伺服器將其創建為一個文件，而這本身可能只是因為客戶端實際上問它會建立一個包含這些特定內容的檔案。
常規 SMB 對符號連結一無所知，而且最常見的 SMB 伺服器（Windows）也很長時間不支援符號連結。因此，各種 SMB 用戶端發明了將符號連結儲存為形狀怪異的常規檔案的方法。
您擁有的特定格式稱為明歇爾+法國符號鏈接，由 macOS 和 Linux“cifs”核心模組使用 - 如果使用該選項安裝共享mfsymlinks，Linux 會識別“XSym”標記並假裝它是客戶端應用程式的符號連結。因此，如果一個客戶端使用此選項，所有其他客戶端也必須使用相同的選項。
不幸的是，如果你想擁有真實的伺服器上的符號鏈接，您將需要使用 SMBv1（又稱“NT1”）並確保伺服器和用戶端都支援“CIFS Unix Extensions”。請注意，這是不是計劃與即將推出的 SMBv3 POSIX 擴充功能一起使用 – Samba 開發人員已明確表示他們不希望再存在創建伺服器端符號連結的功能（由於重大安全問題），並且當 Samba 獲得對 POSIX 功能的支援時在SMBv3 中，它將繼續創建這些“特殊文件”。
作為對原始問題的不同答案，可能是技術上可以使用“debugfs”類型的工具將檔案變更為符號連結並返回，但這在很大程度上取決於該特定檔案系統的內部結構。 （其中一些可能像常規文件一樣存儲符號鏈接，只是類型位不同......但其他像 NTFS 可能具有完全不相容的格式。）
但這通常僅在修復嚴重損壞的檔案系統時執行，而不是作為正常操作的一部分。當然，如果原始「偽符號連結」檔案包含 MF 格式的數據，那麼它不會有任何好處，因為那是不是與檔案系統內部使用的格式相同。