針對 Azure 檔案連線和存取問題進行疑難排解 (SMB)

當您嘗試連線到 Windows 中的 Azure 檔案儲存體共用時，您可能會收到下列錯誤訊息。

掛接 Azure 檔案共用時發生錯誤 5

• 發生系統錯誤 5。 存取遭到拒絕。

原因 1：通訊通道未加密

基於安全考量，如果通訊通道未加密，而且未從 Azure 檔案共用所在的相同資料中心進行連線嘗試，與 Azure 檔案共用的連線就會遭到封鎖。 如果儲存體帳戶上啟用需要安全傳輸設定，則也可能會封鎖相同資料中心內未加密的連線。 唯有當終端使用者的用戶端 OS 支援 SMB 加密時，系統才會提供加密的通訊通道。

Windows 8、Windows Server 2012 和更新版本的每個系統交涉要求，包括 SMB 3。x，支援加密。

原因 1 的解決方案

1. 從支援 SMB 加密的用戶端連線 (Windows 8/Windows Server 2012 或更新版本)。
2. 從與用於 Azure 檔案儲存體共用的 Azure 儲存體帳戶相同資料中心中的虛擬機器 (VM) 進行連線。
3. 如果用戶端不支援 SMB 加密，請確認儲存體帳戶上的需要安全傳輸設定已經停用。

原因 2：在儲存體帳戶上已啟用虛擬網路或防火牆規則

如果在儲存體帳戶上設定虛擬網路 (VNET) 和防火牆規則，網路流量將會被拒絕存取，除非用戶端 IP 位址或虛擬網路已列入允許清單。

原因 2 的解決方案

確認已經在儲存體帳戶上正確設定虛擬網路和防火牆規則。 若要測試虛擬網路或防火牆規則是否造成問題，請暫時將儲存體帳戶上的設定變更為 [允許來自所有網路的存取]。 若要深入了解，請參閱設定 Azure 儲存體防火牆和虛擬網路。

原因 3：使用身分識別型驗證時，共用層級權限不正確

當使用者使用 Active Directory (AD) 或 Microsoft Entra Domain Services 驗證存取 Azure 檔案共用，如果共用層級權限不正確，則存取檔案共用會失敗，並出現「拒絕存取」錯誤。

原因 3 的解決方案

驗證權限的設定是否正確：

• 針對 Active Directory Domain Services (AD DS)，請參閱將共用層級權限指派給身分識別 (機器翻譯)。

  已使用 Microsoft Entra Connect Sync 或 Microsoft Entra Connect 雲端同步，從 AD DS 同步至 Microsoft Entra ID 的群組和使用者，都支援共用層級許可權指派。確認指派共用層級許可權的群組和使用者不受不支援的「僅限雲端」群組。

• Microsoft Entra Domain Services 請參閱指派共用層級權限。

當您嘗試掛接或取消掛接 Azure 檔案共用時發生錯誤 53、錯誤 67 或錯誤 87

當您嘗試從內部部署或不同的資料中心掛接檔案共享時，您可能會收到下列錯誤：

• 發生系統錯誤 53。 找不到網路路徑。
• 發生系統錯誤 67。 找不到網路名稱。
• 發生系統錯誤 87。 參數錯誤。

原因 1：連接埠 445 遭到封鎖

如果連接埠 445 至 Azure 檔案服務資料中心的輸出通訊遭到封鎖，可能會發生系統錯誤 53 或系統錯誤 67。 若要查看 ISP 是否允許從連接埠 445 進行存取的摘要，請參閱 TechNet \(英文\)。

若要檢查您的防火牆或 ISP 是否封鎖連接埠 445，請使用 AzFileDiagnostics 工具或 Test-NetConnection Cmdlet。

若要使用 Test-NetConnection Cmdlet，必須安裝 Azure PowerShell 模組。 如需詳細資訊，請參閱安裝 Azure PowerShell 模組。 請記得以儲存體帳戶的相關名稱取代 <your-storage-account-name> 和 <your-resource-group-name>。

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

如果連線已成功建立，您應該會看到下列輸出：

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

原因 1 的解決方案

解決方案 1—使用 Azure 檔案同步作為 QUIC 端點 您可以使用 Azure 檔案同步作為因應措施，從已封鎖連接埠 445 的用戶端存取 Azure 檔案共用。 儘管 Azure 檔案不直接支援 SMB over QUIC，但 Windows Server 2022 Azure Edition 確實支援 QUIC 通訊協定。 您可以使用 Azure 檔案同步在 Windows Server 2022 Azure Edition VM 上建立 Azure 檔案共用的輕量型快取。此設定使用連接埠 443 (而不是連接埠 445)，此連接埠廣泛開放輸出以支援 HTTPS。 若要深入了解此選項，請參閱 使用 Azure 檔案同步進行 SMB over QUIC。

解決方案 2 - 使用 VPN 或 ExpressRoute 透過設定從內部部署到 Azure 記憶體帳戶的虛擬專用網 （VPN） 或 ExpressRoute，使用私人端點在內部網路上公開 Azure 檔案儲存體，流量會通過安全通道，而不是透過因特網。 請遵循指示來設定 VPN 以從 Windows 存取 Azure 檔案儲存體。

解決方案 3—透過 ISP/IT 系統管理員的協助解除封鎖連接埠 445 請與您的 IT 部門或 ISP 合作，以開啟連接埠 445 輸出至 Azure IP 範圍。

解決方案 4 - 除了 SMB 之外，使用 rest API 型工具，例如 儲存體總管 或 PowerShell Azure 檔案儲存體 也支援 REST。 REST 存取會透過連接埠 443 (標準 TCP) 運作。 許多工具均使用 REST API 撰寫，可帶來豐富的 UI 體驗。 儲存體總管是其中之一。 下載並安裝儲存體總管，並連線到 Azure 檔案儲存體所支援的檔案共用。 您也可以使用 也使用 REST API 的 PowerShell 。

原因 2：已啟用 NTLMv1

如果用戶端上已啟用 NTLMv1 通訊，就可能會發生系統錯誤 53 或系統錯誤 87。 Azure 檔案僅支援 NTLMv2 驗證。 啟用 NTLMv1 會使用戶端變得較不安全。 因此，Azure 檔案服務會封鎖通訊。

若要判斷這是否為錯誤的原因，請確認下列登錄子機碼未設定為小於 3 的值：

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

如需詳細資訊，請參閱 TechNet 上的 LmCompatibilityLevel 主題。

原因 2 的解決方案

在下列登錄子機碼中，將 LmCompatibilityLevel 值還原為預設值 3：

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

失敗，錯誤碼0x800704b3

當您嘗試掛接 Azure 檔案共享時，您會收到下列錯誤：

錯誤碼：0x800704b3
符號名稱：ERROR_NO_NET_OR_BAD_PATH
錯誤描述：網路路徑的類型不正確、不存在，或網路提供者目前無法使用。 請嘗試重新設定路徑，或連絡您的網路管理員。

原因

如果有任何核心 Windows 網路相關服務停用，因為明確相依於這些網路服務的任何服務將無法啟動，就會發生此錯誤。

解決方案

檢查下列任何服務是否處於 Windows VM 的已停止 狀態：

• 網路連線
• 網路清單服務
• 網路定位知悉
• 網路儲存介面服務
• DHCP 用戶端
• TCP/IP NetBIOS 協助程式
• 工作站

如果您發現任何專案，請啟動服務，然後重試掛接 Azure 檔案共用。

應用程式或服務無法存取掛接的 Azure 檔案儲存體 磁碟驅動器

原因

磁碟機是按每個使用者掛接。 如果您的應用程式或服務正在與掛接磁碟機之帳戶不同的使用者帳戶下執行，應用程式將不會看到該磁碟機。

解決方案

使用下列其中一個解決方案：

• 從應用程式所屬的相同使用者帳戶掛接磁碟機。 您可以使用 PsExec 之類的工具。

• 在 net use 命令的使用者名稱和密碼參數中傳遞儲存體帳戶名稱和金鑰。

• 使用 cmdkey 命令以將認證新增至認證管理員。 透過互動式登入或使用 runas，從服務帳戶內容底下的命令列執行這個動作。

  cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
  

• 直接對應共用而不使用對應磁碟機代號。 某些應用程式可能無法正確重新連線到驅動器號，因此使用完整 UNC 路徑可能更可靠：

  net use * \\storage-account-name.file.core.windows.net\share

遵循這些指示執行之後，當您針對系統/網路服務帳戶執行 net use 時，可能會收到下列錯誤訊息：「發生系統錯誤 1312。 指定的登入工作階段不存在。 它可能已經終止了。如果出現此錯誤，請確定傳遞至 net use 包含網域資訊的使用者名稱（例如： [storage account name].file.core.windows.net。

「我的電腦」或「本機」中沒有任何資料夾含有磁碟機代號

如果您以系統管理員身分使用 net use 對應 Azure 檔案共用，該共用似乎就會遺失。

原因

根據預設，Windows 檔案總管不會以管理員身分執行。 如果您從管理命令提示字元執行 net use，就是以系統管理員身分對應網路磁碟機。 由於對應磁碟機是以使用者為中心，因此若磁碟機掛接在其他使用者帳戶下，登入的使用者帳戶不會顯示此磁碟機。

解決方案

從非系統管理員命令掛接共用。 或者，您可以遵循 此 TechNet 主題 來設定 EnableLinkedConnections 登錄值。

如果儲存體帳戶包含斜線，net use 命令就會失敗

原因

net use 命令會將斜線 (/) 解譯為命令列選項。 如果您的使用者帳戶名稱開頭為斜線，磁碟機對應將會失敗。

解決方案

您可以使用下列其中一種方式來解決這個問題：

• 執行下列 PowerShell 命令：

  New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
  

  從批次檔中，您可以使用此方式執行命令：

  Echo new-smbMapping ... | powershell -command –

• 除非斜線是第一個字元，否則，可以用雙引號括住金鑰來解決此問題。 如果是，可使用互動模式分開輸入您的密碼，或者，重新產生金鑰，以取得不是斜線開頭的金鑰。

New-PSDrive 命令失敗，並出現「網路資源類型不正確」錯誤

原因

如果無法存取檔案共用，您可能會看到此錯誤訊息。 例如， 埠 445 遭到 封鎖或發生 DNS 解析問題。

解決方案

請確定埠 445 已開啟，並 檢查 DNS 解析和檔案共用的連線能力。

此問題的常見原因為：

• 您正在使用 Linux 發行版本搭配過期的 SMB 用戶端。 請參閱搭配 Linux 使用 Azure 檔案儲存體，以取得 Azure 中有相容用戶端的通用 Linux 發行版本詳細資訊。
• 用戶端上未安裝 SMB 公用程式 (cifs-utils)。
• 用戶端上無法使用最小 SMB 版本 2.1。
• 用戶端上不支援 SMB 3.x 加密。 上表提供一份 Linux 發行版本清單，支援使用加密從內部部署和跨區域裝載。 其他散發套件需要核心 4.11 和更新版本。
• 您正在嘗試從 Azure VM 連線至 Azure 檔案共用，而該 VM 與儲存體帳戶位於不同的區域。
• 如果儲存體帳戶上已啟用需要安全傳輸設定，則 Azure 檔案服務僅允許使用 SMB 3.x 加密的連線。

解決方案

若要解決此問題，請使用適用於 Linux 上 Azure 檔案服務掛接錯誤的疑難排解工具。 這項工具可以：

• 協助您驗證用戶端執行環境。
• 偵測可能造成 Azure 檔案服務存取錯誤的不相容用戶端設定。
• 提供自行修正的規範指引。
• 收集診斷追蹤。

掛接 Azure 檔案共用時會顯示「掛接錯誤 (13)：權限遭到拒絕」

原因 1：通訊通道未加密

基於安全性考慮，如果通道未加密，且未從 Azure 檔案共用所在的相同數據中心進行連線嘗試，則會封鎖對 Azure 檔案共用的連線。 如果儲存體帳戶上啟用需要安全傳輸設定，則也可能會封鎖相同資料中心內未加密的連線。 只有在使用者的用戶端 OS 支援 SMB 加密時，才會提供加密的通道。

若要深入了解，請參閱以 Linux 和 cifs-utils 套件掛接 Azure 檔案共用的必要條件。

原因 1 的解決方案

1. 從支援SMB加密的用戶端連線，或從與用於Azure檔案共用之 Azure 記憶體帳戶相同資料中心的虛擬機進行連線。
2. 如果用戶端不支援 SMB 加密，請確認儲存體帳戶上的需要安全傳輸設定已經停用。

原因 2：在儲存體帳戶上已啟用虛擬網路或防火牆規則

如果在儲存體帳戶上設定虛擬網路 (VNET) 和防火牆規則，網路流量將會被拒絕存取，除非用戶端 IP 位址或虛擬網路獲准存取。

原因 2 的解決方案

確認已在記憶體帳戶上正確設定 VNET 和防火牆規則，且允許列出埠 445。 若要測試虛擬網路或防火牆規則是否造成問題，您可以暫時將記憶體帳戶上的設定變更為 [允許從所有網络存取]。 若要深入了解，請參閱設定 Azure 儲存體防火牆和虛擬網路。

原因 3：SMB 用戶端已設定為使用 NTLMv1

Azure 檔案儲存體 僅支援SMB檔案共用的NTLMv2和 Kerberos。 核心 4.4 和更新版本預設會啟用 NTLMv2，並停用 LANMAN。 在預設組態下，NTLMv1 會保留為僅限交涉選項。 如需詳細資訊，請參閱您的OS檔。

原因 3 的解決方案

確定SMB掛接命令不會透過 sec 選項覆寫預設NTLMv2驗證。 當 sec 連線到 SMB Azure 檔案分享時，此選項絕對不應該使用 ntlm 或 ntlmi 。 如果您在 /etc/samba/smb.conf 中設定全域選項，請確定您不會停用 NTLMv2。

原因 4：已停用或不允許透過原則存取記憶體帳戶密鑰

停用或不允許記憶體帳戶的記憶體帳戶的記憶體帳戶金鑰存取時，SAS 令牌和存取金鑰將無法運作。

原因 4 的解決方案

使用身分識別型驗證。 檔案共享必須加入 內部部署的 Active Directory Domain Servies （AD DS） 或 Microsoft Entra Domain Services 網域，且 Linux 用戶端必須設定為使用 Kerberos 驗證。

當您使用 SMB 3.x 掛接 Azure 檔案服務時，發生「掛接錯誤 (115)：作業進行中」

原因

部分 Linux 散發套件尚未支援 SMB 3.x 中的加密功能。 如果使用者嘗試使用 SMB 3.x 來掛接 Azure 檔案，可能會因缺少功能而收到「115」錯誤訊息。 只有最新版的Linux發行版才支援具有完整加密的SMB 3.x。

解決方案

Linux 4.11 核心已推出 SMB 3.x 適用的加密功能。 此功能可讓您從內部部署或不同的 Azure 區域掛接 Azure 檔案共用。 某些 Linux 散發套件可能會將 4.11 核心的向後移植變更為其所維護的舊版 Linux 核心。 若要協助判斷您的 Linux 版本是否支援使用加密的 SMB 3.x，請參閱搭配 Linux 使用 Azure 檔案。

如果您的 Linux SMB 用戶端不支援加密，請從與檔案共用位於相同 Azure 資料中心的 Linux VM 使用 SMB 2.1 來掛接 Azure 檔案。 驗證儲存體帳戶上已停用需要安全傳輸設定。

因連線逾時而發生「掛接錯誤 (112)：主機已關機」

當用戶端閒置很長時間時，Linux 用戶端上發生「112」掛接錯誤。 在延長閑置時間之後，用戶端會中斷連線，而聯機逾時。

原因

連線可能因下列原因而閒置：

• 使用預設的「軟式」掛接選項時，網路通訊失敗，導致無法重新建立與伺服器的 TCP 連線。
• 較舊核心中不存在的最新重新連線修正程式。

解決方案

此 Linux 核心中的重新連線問題已隨下列變更修正：

• 修正重新連線在通訊端重新連線許久之後不會延遲 SMB3 工作階段重新連線 (英文)
• 在通訊端重新連線之後立即呼叫 Echo 服務 (英文)
• CIFS：修正重新連線期間可能發生的記憶體損毀 \(英文\)
• CIFS：修正重新連線期間可能發生的 Mutex 雙重鎖定 (針對核心 4.9 版與更新版本) \(英文\)

不過，這些變更可能尚未移植到所有 Linux 發行版。 如果您使用熱門的 Linux 發行版，您可以檢查 [搭配 Linux 使用 Azure 檔案儲存體]，以查看發行版的哪個版本具有必要的核心變更。

因應措施

您可以指定硬掛接，以解決此問題。 硬掛接會強制用戶端一直等候到連線建立或明確中斷為止。 您可用它來防止因網路逾時而發生的錯誤。 不過，這個因應措施可能會導致無限期等候。 請準備好視需要停止連線。

如果您無法升級至最新的核心版本，您可以使用下列因應措施解決此問題：在 Azure 檔案共用中保留一個每 30 秒 (或更短時間) 就會寫入的檔案。 這必須是寫入作業，例如重寫檔案的建立或修改日期。 否則，您可能會取得快取的結果，而您的作業可能不會觸發重新連線。

在 Windows 中，您可能會看到下列錯誤。

孤立的檔案控制代碼或租用

檔案共用的主要目的之一是多個使用者和應用程式可以同時與共用的檔案和目錄進行互動。 為了協助進行這項互動，檔案共用提供數種方式來協調對檔案和目錄的存取。

當您透過 SMB 從掛接的 Azure 檔案共用開啟檔案時，您的應用程式/作業系統會要求檔案控制代碼，這是對檔案的參考。 除此之外，您的應用程式會在要求檔句柄時指定檔案共用模式，以指定您對 Azure 檔案儲存體 所強制執行之檔案存取的獨佔性層級：

• None：您有獨佔存取權。
• Read：其他使用者可以在您開啟檔案時讀取該檔案。
• Write：其他使用者可以在您開啟檔案時寫入該檔案。
• ReadWrite：Read 和 Write 共用模式組合。
• Delete：其他使用者可以在您開啟檔案時進行刪除。

雖然 FileREST 是無狀態通訊協定，並沒有檔案控制代碼的概念，但提供了類似機制，可協調存取指令碼、應用程式或服務可能會使用的檔案和資料夾：檔案租用。 已租用檔案會被視為相當於 None 檔案共用模式的檔案控制代碼。

雖然檔案控制代碼和租用有重要作用，但有時檔案控制代碼和租用可能會是孤立的。 發生這種情況時，可能會導致修改或刪除檔案時出現問題。 您可能會看到如下錯誤訊息：

• 由於已有另一個處理序正在使用該檔案，所以此處理序無法存取該檔案。
• 因為此檔案已在其他程式中開啟，所以無法完成此動作。
• 該文件已被鎖定以供另一個使用者編輯。
• 指定的資源已標示為可供 SMB 用戶端刪除。

此問題的解決方式取決於此問題是否由孤立的檔案控制代碼或租用所造成。

原因 1

檔案控制代碼會防止修改或刪除檔案/目錄。 您可以使用 Get-AzStorageFileHandle PowerShell cmdlet 來檢視開啟的控制代碼。

如果所有 SMB 用戶端都關閉了檔案/目錄上的開啟控制代碼，而且問題持續發生，您可以強制關閉檔案控制代碼。

解決方案 1

若要強制關閉檔案控制代碼，請使用 Close-AzStorageFileHandle PowerShell cmdlet。

原因 2

檔案租用會阻止檔案遭到修改或刪除。 您可以使用下列 PowerShell 命令來檢查檔案是否有檔案租用。 將 <resource-group>、<storage-account>、<file-share> 和 <path-to-file> 取代為您環境適用的值。

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

如果檔案有租用，則傳回的物件應包含下列屬性：

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

解決方案 2

若要從檔案中移除租用，您可以釋放租用或中斷租用。 若要釋放租用，您需要有租用的 LeaseId (您會在建立租用時設定此識別碼)。 您不需要 LeaseId 就能中斷租用。

下列範例示範如何中斷原因 2 中指出的檔案租用 (此範例延續原因 2 中的 PowerShell 變數)：

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

在 Linux 中，您可能會看到下列問題。

檔案或目錄的開啟控制代碼

原因

發生此問題的原因，通常是因為檔案或目錄上有已開啟的控點。

解決方案

如果 SMB 用戶端已關閉所有開啟的控制碼，而問題仍持續發生，請執行下列動作：

• 使用 Get-AzStorageFileHandle PowerShell cmdlet 來檢視開啟的控制代碼。

• 使用 Close-AzStorageFileHandle PowerShell Cmdlet 來關閉開啟的控制碼。

錯誤 1816 - 配額不足，無法處理此命令

原因

若同時開啟的控制代碼數達到 Azure 檔案共用的檔案或目錄所容許的上限時，即會發生錯誤 1816。 如需詳細資訊，請參閱 Azure 檔案服務擴展目標。

解決方案

關閉一些控制代碼以減少同時開啟的控制代碼數，然後再試一次。 如需詳細資訊，請參閱 Microsoft Azure 儲存體效能與延展性檢查清單。

若要檢視為檔案共用、目錄或檔案開啟的控制代碼，請使用 Get-AzStorageFileHandle PowerShell cmdlet。

若要關閉為檔案共用、目錄或檔案開啟的控制代碼，請使用 Close-AzStorageFileHandle PowerShell cmdlet。

在控制代碼上執行任何作業時出現 ERROR_UNEXP_NET_ERR (59)

原因

如果您長期快取/保留大量開啟控制代碼，可能會因為節流的緣故看到此伺服器端失敗。 用戶端快取大量控制代碼時，其中許多控制代碼可能會同時進入重新連線階段，在需要節流的伺服器上增加佇列。 為了重新連線，後端的重試邏輯和節流所花費的時間一旦超過用戶端的逾時時間， 就會導致用戶端無法將現有控制代碼用於任何作業上，因而使所有作業失敗，並顯示 ERROR_UNEXP_NET_ERR (59)。

在一些邊緣案例中，用戶端控制代碼會中斷與伺服器之間的連線 (例如網路中斷數分鐘)，這也可能會造成此錯誤發生。

解決方案

請勿保留大量快取的句柄。 關閉句柄，然後重試。 使用 Get-AzStorageFileHandle 和 Close-AzStorageFileHandle PowerShell Cmdlet 來檢視/關閉開啟控制代碼。

如果您使用 Azure 檔案共享來儲存大型虛擬桌面部署的配置檔容器或磁碟映像，或開啟檔案、目錄和/或根目錄句柄的其他工作負載，您可能會達到並行開啟句柄的上限。 在此情況下，請使用額外的 Azure 檔案共用，並在共用之間散發容器或映像。

當您嘗試開啟檔案時，「[使用權限被拒] 超出磁碟配額」

在 Linux 中，您可能會收到類似以下內容的錯誤訊息︰

<filename> [許可權遭拒] 超過磁碟配額

原因

您已達到檔案或目錄所允許的同時開啟控制代碼上限。

Azure 檔案支援根目錄上的 10,000 個開啟控制代碼，以及共用內每個檔案和目錄 2,000 個開啟控制代碼。

解決方案

關閉某些句柄，然後重試作業，以減少並行開啟句柄的數目。

若要檢視為檔案共用、目錄或檔案開啟的控制代碼，請使用 Get-AzStorageFileHandle PowerShell cmdlet。

若要關閉為檔案共用、目錄或檔案開啟的控制代碼，請使用 Close-AzStorageFileHandle PowerShell cmdlet。