共用方式為

針對 Linux 中的 Azure 檔案儲存體問題進行疑難排解 (SMB)

  • 發行項

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

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

重要

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

適用於

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

複製檔案時遺失時間戳

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

原因

COPYFILE 中的強制旗標 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 或 SMB 3 通訊協定，建立 Windows 樣式的符號連結。 Linux 用戶端目前支援另一種符號連結樣式，稱為 Minshall+French symlinks (Mishall + 法文符號連結)，可用於建立和遵循作業。 需要符號連結的客戶可以使用 "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 問題

掛接檔案系統上的檔案輸入/輸出開始出現「主機已關閉」或「使用權限被拒」錯誤。 用戶端上的 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 位址。 此問題可能會在伺服器 IP 位址變更的任何案例中發生，例如帳戶移轉。 另一個已知案例是記憶體帳戶故障轉移，因為 DNS 對應可能會變更。

原因

為了達到容量負載平衡，儲存體帳戶有時會即時從一個儲存體叢集移轉至另一個儲存體叢集。 帳戶移轉會觸發將 Azure 檔案儲存體流量從來源叢集重新導向至目的地叢集，方法是更新 DNS 對應以指向目的地叢集。 這會封鎖從該帳戶到來源叢集的所有流量。 預期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 核心。 下列散發版本具有修正：

  • Ubuntu：20.04、22.04、24.04 和 AKS 22.04 （修正程式會在核心版本 5.15.0-1068 中推出）
  • RHEL：8.6+
  • SLES：15SP2、15SP3、15SP4 和 15SP5
  • Azure Linux：2.0（修正會在核心 5.15.159.1 版中推出）和 3.0

有些散發版本已反轉這些修正程式。 您可以檢查下列修正程式是否存在於您使用的發行版中：

啟用 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. 將中的 /etc/sysctl.confsysctl 值crypto.fips_enabled變更為 0。

  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 意見反應社群提交產品意見反應。