針對 NFS Azure 檔案共用問題進行疑難排解
注意
本文所參考的 CentOS 是一種 Linux 發行版,且將到達生命周期結束(EOL)。 請據以考慮您的使用和規劃。 如需詳細資訊,請參閱 CentOS 生命週期結束指引。
本文列出與 NFS Azure 檔案共用相關的常見問題,並提供可能的原因和因應措施。
重要
本文內容僅適用於 NFS 共用。 若要針對 Linux 中的 SMB 問題進行疑難排解,請參閱針對 Linux 中的 Azure 檔案儲存體問題進行疑難排解 (SMB)。 Windows 不支援 NFS Azure 檔案共用。
適用於
檔案共用類型 | SMB | NFS |
---|---|---|
標準檔案共用 (GPv2)、LRS/ZRS | ||
標準檔案共用 (GPv2)、GRS/GZRS | ||
進階檔案共用 (FileStorage)、LRS/ZRS |
chgrp "filename" 失敗:引數不正確 (22)
原因 1:idmapping 未停用
因為 Azure 檔案儲存體不允許英數字元 UID/GID,因此您必須停用 idmapping。
原因 2:idmapping 已停用,但是在遇到錯誤的檔案/目錄名稱之後重新啟用
即使您已正確停用 idmapping,在某些情況下仍可能會自動重新啟用。 例如,當 Azure 檔案儲存體遇到錯誤的檔案名稱時,便會傳回錯誤。 看到此錯誤碼時,NFS 4.1 Linux 用戶端會決定重新啟用 idmapping,並使用英數字元 UID/GID 傳送未來的要求。 如需 Azure 檔案儲存體上不支援的字元清單,請參閱這篇文章。 冒號是其中一個不支援的字元。
因應措施
請確定您已停用 idmapping,且未重新啟用任何項目。 然後執行下列步驟:
將共用取消掛接。
使用停用 idmapping:
sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
掛接共用。
如果執行 rsync,請從沒有不良目錄或檔名的目錄,使用
—numeric-ids
自變數執行 rsync。
無法建立 NFS 共用
原因:不支持的記憶體帳戶設定
NFS 僅適用於具有下列設定的儲存體帳戶:
- 層級 - 進階
- 帳戶種類 - FileStorage
- 區域 - 支援的區域清單
解決方案
請遵循如何建立 NFS 共用中的指示。
無法連線至或裝載 NFS Azure 檔案共用
原因 1:要求源自不受信任網路/不受信任 IP 中的用戶端
與 SMB 不同的是,NFS 沒有以使用者為基礎的驗證。 共用的驗證是以您的網路安全性規則設定為基礎。 若要確保用戶端只會建立與 NFS 共用的安全連線,您必須使用服務端點或私人端點。 除了私人端點之外,若要從內部部署存取共用,您必須設定 VPN 或 ExpressRoute 連線。 會忽略針對防火牆新增至儲存體帳戶允許清單的 IP。 您必須使用下列其中一種方法來設定 NFS 共用的存取權:
原因 2:已啟用需要安全傳輸
NFS Azure 檔案共用目前不支援雙重加密。 Azure 會使用 MACSec,為 Azure 資料中心之間傳輸中的所有資料提供加密層級。 您只能從受信任的虛擬網路以及透過 VPN 通道存取 NFS 共用。 NFS 共用上沒有額外可用的傳輸層加密。
解決方案
停用 記憶體帳戶設定刀鋒視窗中所需的 安全傳輸。
原因 3:未安裝 nfs-utils、nfs-client 或 nfs-common 套件
執行 mount
命令之前,請先安裝 nfs-utils、nfs-client 或 nfs-common 套件。
若要檢查是否已安裝 NFS 套件,請執行:
解決方案
如果未安裝套件,請使用您的發行版本特定命令來安裝套件。
本節中的相同命令適用於 CentOS 和 Oracle Linux。
OS 7.X 版
sudo yum install nfs-utils
作業系統版本 8.X 或 9.X
sudo dnf install nfs-utils
原因 4:防火牆封鎖連接埠 2049
NFS 通訊協定會透過埠 2049 與其伺服器通訊。 請確定此連接埠已開啟至儲存體帳戶 (NFS 伺服器)。
解決方案
執行下列命令,確認用戶端上已開啟連接埠 2049。 如果連接埠未開啟,請將其開啟。
sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049
原因 5:記憶體帳戶已刪除
如果您因為錯誤而無法掛接檔案共享 :連線逾時,可能會意外刪除包含檔案共用的記憶體帳戶。
解決方案
復原記憶體帳戶。 然後,刪除並重新建立私人端點,使其與新的記憶體帳戶資源標識符相關聯。
在某些核心上大型目錄列舉停止回應
原因:Linux 核心 v5.11 中引進錯誤,並在 v5.12.5 中修正
某些核心版本含有錯誤,其會導致目錄清單產生無限的 READDIR 序列。 所有項目都可以在一次呼叫中寄出的小型目錄不會有該問題。 錯誤是在 Linux 核心 v 5.11 中引進,並已在 v 5.12.5 中修正。 這兩者之間的任何項目都有錯誤。 RHEL 8.4 具有此核心版本。
因應措施:降級或升級核心
將核心降級或升級至受影響核心以外的任何項目,應該可解決此問題。
系統命令失敗,並出現「找不到檔案」錯誤
原因
依賴 inode 數位的 Linux 32 位應用程式可能無法如預期般運作,Azure 檔案儲存體,因為 NFS 服務所產生的 64 位 inode 數位的格式設定。
解決方案
若要解決這個問題,請使用下列其中一個方法:
使用
nfs.enable_ino64=0
核心開機選項,將 64 位 inode 數字壓縮為 32 位。將 新增
options nfs enable_ino64=0
至 /etc/modprobe.d/nfs.conf 檔案並重新啟動 VM,以設定模塊參數。
您也可以在 grub.conf 檔案中保存此核心開機選項。 如需詳細資訊,請參閱 Linux 發行版的檔。
無法變更檔案和目錄的擁有權
原因
用戶端OS會強制執行NFS檔案共享的許可權,而不是 Azure 檔案儲存體服務。 如果在 NFS 檔案共享上啟用 Root Squash 設定,客戶端系統上的根用戶會被視為匿名(非特殊許可權)使用者,以供存取控制之用。 這表示即使您在客戶端系統上以根目錄登入,您也無法使用 chown
命令來變更您不擁有的檔案和目錄擁有權。
解決方案
在 Azure 入口網站 中,流覽至檔案共享,然後選取 [屬性]。 將 [根壁球 ] 設定變更為 [無根壁球]。 如需詳細資訊,請參閱設定 Azure 檔案儲存體 的根壁球。
啟用 Root Squash 後,客戶端系統上的根使用者具有與伺服器系統上根使用者相同的許可權。 您現在 chown
可以使用 來變更共用中任何檔案或目錄的擁有權,而不論目前的擁有者為何。 進行變更之後,您可以視需要重新啟用 Root Squash 。
需要協助嗎?
如果仍需要協助,請連絡支援人員以快速解決您的問題。
另請參閱
- 針對 Azure 檔案進行疑難排解
- 針對 Azure 檔案儲存體效能進行疑難排解
- 針對 Azure 檔案儲存體連線進行疑難排解 (SMB)
- 針對 Azure 檔案儲存體驗證和授權進行疑難排解 (SMB)
- 針對 Linux 上的 Azure 檔案一般 SMB 問題進行疑難排解
與我們連絡,以取得說明
如果您有問題或需要相關協助,請建立支援要求,或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。