共用方式為

針對 Linux (SMB) 中的 Azure 檔案服務問題進行疑難解答

  • 發行項

本文列出搭配Linux用戶端使用SMB Azure檔案共用時可能發生的常見問題。 它也提供這些問題的可能原因和解決方法。

您可以使用 AzFileDiagnostics 將徵兆偵測自動化，並確保 Linux 用戶端具有正確的必要條件。 它可協助您設定環境以獲得最佳效能。 您也可以在 Azure 檔案共用疑難解答員中找到這項資訊。

重要事項

本文僅適用於SMB共用。 如需 NFS 共用的詳細資訊，請參閱 針對 NFS Azure 檔案共用進行疑難解答。

適用於

檔案共享類型 SMB NFS
GPv2) 、LRS/ZRS (標準檔案共用
GPv2) 、GRS/GZRS (標準檔案共用
FileStorage) 、LRS/ZRS (進階檔案共用

複製檔案時遺失時間戳

在 Linux/Unix 平臺上 cp -p ，如果不同的使用者擁有檔案 1 和檔案 2，命令就會失敗。

原因

COPYFILE 中的 force 旗標 f 會導致在 Unix 上執行 cp -p -f 。 此命令也無法保留您不擁有之檔案的時間戳。

因應措施

使用記憶體帳戶使用者來複製檔案：

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls： 無法存取 '<path>'： 輸入/輸出錯誤

當您嘗試使用 ls 命令列出 Azure 檔案共用中的檔案時，命令會在列出檔案時停止回應。 您會收到下列錯誤：

ls： 無法存取'<path>'： 輸入/輸出錯誤

解決方案

將 Linux 核心升級至下列版本，以修正此問題：

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • 所有大於或等於 4.13 的版本

無法建立符號連結 - ln： 無法建立符號連結 't'： 不支持作業

原因

根據預設，使用SMB在Linux上掛接 Azure 檔案共用並不會支援符號連結 (符號連結) 。 您可能會看到如下的錯誤：

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

解決方案

Linux SMB 用戶端不支援透過SMB 2或3通訊協定建立 Windows 樣式符號連結。 目前，Linux 用戶端支援另一種樣式的符號連結 ，稱為 Mins 要+法文符號連結 ，以進行建立和追蹤作業。 需要符號連結的客戶可以使用 「mfsymlinks」 掛接選項。 我們建議使用 「mfsymlinks」，因為它也是 Mac 使用的格式。

若要使用符號連結，請將下列內容新增至SMB掛接命令的結尾：

,mfsymlinks

因此，命令看起來如下所示：

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

然後，您可以依照 Wiki上的建議建立符號連結。

無法存取名稱結尾有空格或點的資料夾或檔案

在 Linux 上掛接時，您無法從 Azure 檔案共用存取資料夾或檔案。 du 和 ls 及/或第三方應用程式等命令在存取共用時可能會失敗，並出現「沒有這類檔案或目錄」錯誤;不過，您可以透過 Azure 入口網站將檔案上傳至這些資料夾。

原因

資料夾或檔案是從將名稱結尾的字元編碼為不同字元的系統上傳。 從 Macintosh 電腦上傳的檔案可能有「0xF028」或「0xF029」字元，而不是0x20 (空格) 或0X2E (点) 。

解決方案

在 Linux 上掛接共用時，請在共用上使用 mapchars 選項：

而不是：

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

用：

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Azure 記憶體帳戶即時移轉的 DNS 問題

掛接的文件系統上的檔案 I/O 開始出現「主機已關閉」或「許可權遭拒」錯誤。 用戶端上的 Linux dmesg 記錄會顯示重複的錯誤，例如：

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

您也會看到伺服器 FQDN 現在會解析為與其目前連線的 IP 位址不同的 IP 位址。

原因

基於容量負載平衡的目的，記憶體帳戶有時會從一個記憶體叢集即時移轉到另一個記憶體叢集。 帳戶移轉會藉由更新 DNS 對應以指向目的地叢集，觸發要從來源叢集重新導向至目的地叢集的 Azure 檔案記憶體流量。 這會封鎖從該帳戶流向來源叢集的所有流量。 SMB 用戶端應該會挑選 DNS 更新，並將更多流量重新導向至目的地叢集。 不過，由於Linux SMB核心用戶端中的錯誤，此重新導向不會生效。 因此，數據流量會持續流向來源叢集，而來源叢集在移轉後已停止為此帳戶提供服務。

因應措施

您可以重新啟動用戶端 OS 來減輕此問題，但如果您未將用戶端 OS 升級至具有帳戶移轉支援的 Linux 發行版，可能會再次遇到此問題。

雖然卸除和重新掛接共用似乎暫時解決此問題，但這不是永久的解決方案。 當用戶端重新連線到伺服器時，問題可能會再次發生。 發生暫時性風險降低是因為新的掛接動作略過SMB核心快取，並解析用戶空間中的 DNS 位址。 不過，核心 DNS 快取會在任何網路中斷連線復原期間使用，這可能會導致問題重複發生。 即使在記憶體帳戶移轉之外，此行為仍會持續存在。

若要進一步解決此問題，請清除核心 DNS 解析程式快取：

  1. 執行下列命令來顯示核心 dns_resolver 模組的狀態：

    grep '.dns_resolver' /proc/keys

    您應該看到類似下列範例的指令輸出：

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. 執行下列命令來清除核心 DNS 解析程式快取：

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. 再次顯示核心 dns_resolver 模組的狀態：

    grep '.dns_resolver' /proc/keys

    您應該看到類似下列範例的指令輸出，指出快取現在是空的：

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. 卸除並重新掛接共用以減輕問題。

注意事項

在某些較舊的Linux發行版上，上述風險降低步驟可能無法運作。 在這種情況下，重新啟動用戶端OS是唯一已知的風險降低措施。

解決方案

如需永久修正，請使用帳戶移轉支援，將您的用戶端OS升級至Linux發行版。 Linux SMB 核心客戶端的數個修正已提交至主要 Linux 核心。 核心版本 5.15+ 和 Keyutils-1.6.2+ 有修正程式。 有些發行版已回溯這些修正，您可以檢查您所使用的散發版本中是否存在下列修正：

啟用 FIPS 時無法掛接 SMB 檔案共用

在 Linux VM 中啟用 美國聯邦資訊處理標準 (FIPS) 時，就無法掛接 SMB 檔案共用。 用戶端上的 Linux dmesg 記錄會顯示錯誤，例如：

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

重要事項

FIPS 是美國政府用來確保計算機系統安全性和完整性的一組標準。 當系統處於 FIPS 模式時，它會遵守這些標準所述的特定密碼編譯需求。

原因

SMB 檔案共用的用戶端會使用 NTLMSSP 驗證，這需要 MD5 哈希演算法。 不過，在 FIPS 模式中，MD5 演算法會受到限制，因為它不符合 FIPS 規範。 MD5 是廣泛使用的哈希函式，可產生 128 位哈希值。 不過，基於密碼編譯目的，MD5 被視為不安全。

如何檢查是否已啟用 FIPS 模式

若要確認用戶端上是否已啟用 FIPS 模式，請執行下列命令。 如果值設定為 1，則會啟用 FIPS。

sudo cat /proc/sys/crypto/fips_enabled

解決方案

若要解決此問題，請啟用SMB檔案共用的 Kerberos 驗證。 如果無意中啟用 FIPS，請參閱 option2 來停用它。

選項 1：啟用 SMB 檔案共用的 Kerberos 驗證

若要在已啟用 FIPS 的 Linux VM 上掛接 SMB 檔案共用，請使用 Kerberos/Azure AD 驗證。 如需詳細資訊，請參閱 為存取 Azure 檔案記憶體的 Linux 用戶端啟用透過 SMB 的 Active Directory 驗證。

選項 2：停用 FIPS 以掛接 Samba 共用

  1. 在 中，將 的 crypto.fips_enabled sysctl 值變更為 0 /etc/sysctl.conf。

  2. GRUB_CMDLINE_LINUX_DEFAULT變更檔案中的 /etc/default/grub ，並移除 參數 fips=1。

  3. 使用下列命令重建 grub2 組態檔：

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. 使用下列命令重建 initramfs 映射：

    sudo dracut -fv

  5. 重新啟動 VM。

如需詳細資訊，請參閱來自Linux散發者的下列檔：

需要協助？

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

另請參閱

與我們連絡，以取得說明

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