針對 NFS Azure 檔案共用問題進行疑難排解

本文列出與 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，且未重新啟用任何項目。 然後執行下列步驟：

1. 將共用取消掛接。

2. 使用停用 idmapping：

   sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

3. 掛接共用。

4. 如果執行 rsync，請從沒有不良目錄或檔名的目錄，使用 —numeric-ids 自變數執行 rsync。

無法建立 NFS 共用

原因：不支持的記憶體帳戶設定

NFS 僅適用於具有下列設定的儲存體帳戶：

• 層級 - 進階
• 帳戶種類 - FileStorage
• 區域 - 支援的區域清單

解決方案

請遵循如何建立 NFS 共用中的指示。

無法連線至或裝載 NFS Azure 檔案共用

原因 1：要求源自不受信任網路/不受信任 IP 中的用戶端

與 SMB 不同的是，NFS 沒有以使用者為基礎的驗證。 共用的驗證是以您的網路安全性規則設定為基礎。 若要確保用戶端只會建立與 NFS 共用的安全連線，您必須使用服務端點或私人端點。 除了私人端點之外，若要從內部部署存取共用，您必須設定 VPN 或 ExpressRoute 連線。 會忽略針對防火牆新增至儲存體帳戶允許清單的 IP。 您必須使用下列其中一種方法來設定 NFS 共用的存取權：

• 服務端點

  • 由公用端點存取。

  • 僅適用於相同的區域。

  • 您無法使用 VNet 對等互連進行共用存取。

  • 您必須將每個虛擬網路或子網個別新增至允許清單。

  • 對於內部部署存取，可以使用服務端點搭配 ExpressRoute、點對站和站對站 VPN。 我們建議使用私人端點，因為它更安全。

    下圖描述使用公用端點的連線：

    

• 私人端點

  • 存取比服務端點更安全。

  • 可以從記憶體帳戶的 Azure 區域內部和外部 (跨區域、內部部署) 透過私人連結存取 NFS 共用。

  • 虛擬網路對等互連與裝載在私人端點中的虛擬網路，可讓 NFS 共用存取對等互連虛擬網路中的用戶端。

  • 您可以搭配 ExpressRoute、點對站 VPN 和站對站 VPN 使用私人端點。

    

原因 2：已啟用需要安全傳輸

NFS Azure 檔案共用目前不支援雙重加密。 Azure 會使用 MACSec，為 Azure 資料中心之間傳輸中的所有資料提供加密層級。 您只能從受信任的虛擬網路以及透過 VPN 通道存取 NFS 共用。 NFS 共用上沒有額外可用的傳輸層加密。

解決方案

停用 記憶體帳戶設定刀鋒視窗中所需的 安全傳輸。

原因 3：未安裝 nfs-utils、nfs-client 或 nfs-common 套件

執行 mount 命令之前，請先安裝 nfs-utils、nfs-client 或 nfs-common 套件。

若要檢查是否已安裝 NFS 套件，請執行：

sudo rpm -qa | grep nfs-utils

sudo rpm -qa | grep nfs-client

sudo dpkg -l | grep nfs-common

解決方案

如果未安裝套件，請使用您的發行版本特定命令來安裝套件。

sudo yum install nfs-utils

sudo dnf install nfs-utils

sudo zypper install nfs-client

sudo apt update
sudo apt install nfs-common

原因 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 具有此核心版本。

因應措施：降級或升級核心

將核心降級或升級至受影響核心以外的任何項目，應該可解決此問題。

系統命令失敗，並出現「找不到檔案」錯誤

原因

由於 NFS 服務所產生的 64 位 inode 數位格式設定，依賴 inode 數位的 Linux 32 位應用程式可能無法如預期般運作 Azure 檔案儲存體。

解決方案

若要解決這個問題，請使用下列其中一個方法：

• 使用 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 入口網站 中，流覽至檔案共享，然後選取 [屬性]。 將 [根壁球 ] 設定變更為 [無根壁球]。

啟用 Root Squash 後，客戶端系統上的根使用者具有與伺服器系統上根使用者相同的許可權。 您現在 chown 可以使用 來變更共用中任何檔案或目錄的擁有權，而不論目前的擁有者為何。 進行變更之後，您可以視需要重新啟用 Root Squash 。

需要協助嗎？

如果仍需要協助，請連絡支援人員以快速解決您的問題。

另請參閱

• 針對 Azure 檔案進行疑難排解
• 針對 Azure 檔案儲存體效能進行疑難排解
• 針對 Azure 檔案儲存體連線進行疑難排解 (SMB)
• 針對 Azure 檔案儲存體驗證和授權進行疑難排解 (SMB)
• 針對 Linux 上的 Azure 檔案一般 SMB 問題進行疑難排解

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。