共用方式為

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

  • 發行項

本文列出當您嘗試從 Windows 或 Linux 用戶端連線及存取伺服器消息塊 （SMB） Azure 檔案共享時可能發生的常見問題。 文中也會提供這些問題的可能原因和解決方案。

注意

本篇文章實用嗎？ 您的輸入對我們很重要。 請使用此頁面上的 [ 意見反應 ] 按鈕，讓我們知道這篇文章為您運作得有多好，或我們如何加以改善。

重要

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

適用於

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

無法連線或掛接 Azure 檔案共用

根據您用來存取 Azure 檔案共享的用戶端作業系統，選取 [Windows] 或 [Linux] 索引標籤。

當您嘗試連線到 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

注意

此命令會傳回記憶體帳戶的目前IP位址。 此 IP 位址不保證會維持不變，而且可能隨時變更。 請勿將此 IP 位址硬式編碼到任何指令碼或防火牆設定中。

原因 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 解析和檔案共用的連線能力。

無法存取、修改或刪除 Azure 檔案共用 (或共用快照集)

客戶起始的故障轉移之後，「使用者名稱或密碼不正確」錯誤

在具有異地備援記憶體帳戶的客戶起始故障轉移案例中，不會在故障轉移時保留檔句柄和租用。 用戶端必須卸除並重新掛接檔案共用。

當您嘗試存取或刪除 Azure 檔案共用時，發生「無存取權」錯誤

當您嘗試使用 Azure 入口網站存取或刪除 Azure 檔案共用時，可能會收到下列錯誤：

沒有存取錯誤碼：403

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

原因 1 的解決方案

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

原因 2：您的使用者帳戶沒有該儲存體帳戶的存取權

原因 2 的解決方案

流覽至 Azure 檔案共用所在的記憶體帳戶，選取 [存取》[存取 ][IAM]，並確認您的用戶帳戶具有記憶體帳戶的存取權。 若要深入了解，請參閱如何使用 Azure 角色型存取控制 (Azure RBAC) 保護儲存體帳戶。

檔案鎖定和租用

如果您無法修改或刪除 Azure 檔案共用或快照集，可能是因為檔案鎖定或租用所致。 Azure 檔案儲存體提供兩種方式來防止意外修改或刪除 Azure 檔案共用和共用快照集：

  • 儲存體帳戶資源鎖定：所有資源 (包括儲存體帳戶在內) 都支援資源鎖定。 鎖定可能會由系統管理員或 Azure 備份 等服務放在記憶體帳戶上。 資源鎖定有兩種變化： modify，這可防止對記憶體帳戶及其資源進行所有修改，並 刪除，這隻會防止刪除記憶體帳戶及其資源。 透過 Microsoft.Storage 資源提供者修改或刪除共用時，會對 Azure 檔案共用和共用快照集強制執行資源鎖定。 大部分的入口網站作業、適用於 Azure 檔案儲存體 Rm Get-AzRmStorageShare的 Azure PowerShell Cmdlet，以及命令群組中的 share-rm Azure CLI 命令，az storage share-rm list都會使用Microsoft.Storage資源提供者。 某些工具和公用程式，例如 儲存體總管、舊版 Azure 檔案儲存體 PowerShell 管理 Cmdlet Rm 的名稱（例如az storage share listGet-AzStorageShare，），以及命令群組下的share舊版 Azure 檔案儲存體 CLI 命令，使用 FileREST API 中的舊版 API，以略過Microsoft.Storage資源提供者和資源鎖定。 如需 FileREST API 中公開的舊版管理 API 相關詳細資訊，請參閱 Azure 檔案儲存體中的控制平面。

  • 共用/共用快照集租用：共用租用是某種類型的 Azure 檔案共用和檔案共用快照集專用鎖定。 租用可能會由系統管理員透過腳本呼叫 API，或透過 Azure 備份 等增值服務呼叫 API，將租用放在個別的 Azure 檔案共用或檔案共用快照集上。 對 Azure 檔案共用或檔案共用快照集施行租用時，可以使用租用識別碼來修改或刪除檔案共用/共用快照集。 系統管理員也可以在修改作業之前釋放租用，這需要租用標識符，或中斷租用，而不需要租用標識符。 如需共用租用的詳細資訊，請參閱租用共用。

由於資源鎖定和租用可能會干擾儲存體帳戶/Azure 檔案共用上預定的系統管理員作業，因此建議您移除由系統管理員手動或由加值型服務 (例如 Azure 備份) 自動對資源施加的任何資源鎖定/租用。 下列指令碼會移除所有資源鎖定和租用。 請記得將 <resource-group> 和 <storage-account> 取代為您環境適用的值。

執行下列指令碼之前，您應該安裝最新版的 Azure 記憶體 PowerShell 模組。

重要

在 Azure 檔案儲存體資源上採用資源鎖定和共用/共用快照集租用的加值型服務，可以定期重新套用鎖定和租用。 透過加值服務修改或刪除鎖定的資源可能會影響這些服務的一般作業，例如刪除由 Azure 備份 管理的共用快照集。

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

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

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

無法修改、移動/重新命名或刪除檔案或目錄

根據您用來存取 Azure 檔案共用的用戶端作業系統，選取 Windows 或 Linux 索引標籤。

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

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

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

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

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

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

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

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

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

注意

應用程式會使用 REST 租用來防止檔案遭到刪除或修改。 在中斷任何租用之前，您應該先識別要取得哪些應用程式。 否則，您可能會中斷應用程式行為。

原因 1

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

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

解決方案 1

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

注意

Az PowerShell 模組 2.4 以上版本內含 Get-AzStorageFileHandle 與 Close-AzStorageFileHandle Cmdlet。 若要安裝最新的 Az PowerShell 模組，請參閱安裝 Azure PowerShell 模組。

原因 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 上掛接 Azure 檔案共用快照集

嘗試在 Linux 上掛接 Azure 檔案共用快照集時，「掛接錯誤 (22)：無效的引數」

原因

如果 mount 命令的 snapshot 選項未以辨識的格式傳遞，mount 命令可能會失敗，並出現此錯誤。 若要確認，請檢查核心記錄訊息 （dmesg），而 dmesg 會顯示記錄專案，例如 cifs: Bad value for 'snapshot'。

解決方案

請確定您以正確的格式傳遞 mount 命令的 snapshot 選項。 請參閱 mount.cifs 手冊頁 (例如 man mount.cifs)。 常見的錯誤是以錯誤格式傳遞 GMT 時間戳記，例如使用連字號或冒號來取代句號。 如需詳細資訊，請參閱掛接檔案共用快照集。

嘗試在 Linux 上掛接 Azure 檔案共用快照集時出現「錯誤快照集權杖」

原因

如果以 @GMT 開始傳遞快照集 mount 選項，但格式仍然錯誤 (例如使用連字號和冒號而非句號)，mount 命令可能會失敗，並出現此錯誤。

解決方案

請確定您以正確的格式傳遞 GMT 時間戳，也就是 @GMT-year.month.day-hour.minutes.seconds。 如需詳細資訊，請參閱掛接檔案共用快照集。

嘗試掛接 Azure 檔案共用快照集時，出現「掛接錯誤 (2)：沒有此類檔案或目錄」

原因

如果您嘗試掛接的快照集不存在， mount 命令可能會失敗，並出現此錯誤。 若要確認，請檢查核心記錄訊息 （dmesg），而 dmesg 會顯示記錄專案，例如：

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

解決方案

請確定您嘗試掛接的快照集存在。 如需如何列出指定 Azure 檔案共用的可用快照集的詳細資訊，請參閱掛接檔案共用快照集。

由於開啟控制代碼太多而導致磁碟配額或網路錯誤

根據您用來存取 Azure 檔案共用的用戶端作業系統，選取 Windows 或 Linux 索引標籤。

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

原因

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

解決方案

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

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

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

注意

Az PowerShell 模組 2.4 以上版本內含 Get-AzStorageFileHandle 與 Close-AzStorageFileHandle Cmdlet。 若要安裝最新的 Az PowerShell 模組，請參閱安裝 Azure PowerShell 模組。

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

原因

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

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

解決方案

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

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

「您正將檔案複製到不支援加密的目的地」錯誤

透過網路複製檔案時，該檔案會在來源電腦上解密、以純文字傳送，並在目的地上重新加密。 不過，您可能會在嘗試複製加密的檔案時看到下列錯誤：「您正在將檔案複製到不支援加密的目的地。」

原因

如果您使用加密檔案系統 (EFS)，可能會發生此問題。 BitLocker 加密的檔案可以複製到 Azure 檔案服務。 不過，Azure 檔案儲存體不支援 NTFS EFS。

因應措施

若要透過網路複製檔案，您必須先將它解密。 使用下列其中一種方法：

  • 使用 copy /d 命令。 它可讓加密的檔案另存為目的地上的解密檔案。
  • 設定下列登錄機碼：
    • 路徑 = HKLM\Software\Policies\Microsoft\Windows\System
    • 數值類型 = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Value = 1

請注意，設定登錄機碼會影響所有對網路共用所做的複製作業。

透過瀏覽器使用 Azure 檔案儲存體的 Web 應用程式傳回錯誤 ConditionHeadersNotSupported

當透過使用條件式標頭的應用程式 (例如網頁瀏覽器) 存取 Azure 檔案儲存體中的代管內容時，發生 ConditionHeadersNotSupported 錯誤，存取會失敗。 錯誤指出不支持條件標頭。

顯示 ConditionHeadersNotSupported 錯誤訊息的螢幕快照。

原因

尚未支援條件式標頭。 每次存取檔案時，實作這些標頭的應用程式都必須要求完整的檔案。

因應措施

上傳新檔案時， CacheControl 屬性預設為 no-cache。 若要強制應用程式每次要求檔案，檔案的 CacheControl 屬性必須從 no-cache 更新為 no-cache、no-store、must-revalidate。 您可以使用 Azure 儲存體總管來達成此目的。

顯示 CacheControl 檔案屬性的 Screeshot。

另請參閱

與我們連絡，以取得說明

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