針對SMB) (Azure 檔案儲存體連線能力和存取問題進行疑難解答

發行項
04/28/2024

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

注意事項

本文是否有幫助？您的輸入對我們很重要。請使用此頁面上的 [ 意見反應 ] 按鈕，讓我們知道本文如何為您運作，或我們如何加以改善。

重要事項

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

適用於

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

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

Windows
Linux

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

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

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

原因 1：未加密的通道

為了安全起始，如果通道未加密，而且連線嘗試不是從 Azure 檔案共用所在的相同數據中心進行，則會封鎖對 Azure 檔案共用的連線。如果記憶體帳戶上已啟用 [需要安全傳輸 ] 設定，也會封鎖相同數據中心內未加密的連線。只有在使用者的用戶端 OS 支援 SMB 加密時，才會提供加密的通道。

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

原因 1 的解決方案

從支援SMB加密 (Windows 8/Windows Server 2012 或更新版本) 的用戶端連線。
從虛擬機 (VM 連線，) 與用於 Azure 檔案共用的 Azure 記憶體帳戶位於相同的數據中心。
如果客戶端不支援 SMB 加密，請確認記憶體帳戶上的 [ 需要安全傳輸 ] 設定已停用。

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

如果在記憶體帳戶上設定虛擬網路 (VNET) 和防火牆規則，則會拒絕網路流量，除非允許列出用戶端 IP 位址或虛擬網路。

原因 2 的解決方案

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

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

原因 3 的解決方案

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

Active Directory 網域服務 (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。若要查看允許或不允許從埠 445 存取的 ISP 摘要，請移至 TechNet。

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

若要使用 CmdletTest-NetConnection，必須安裝 Azure PowerShell 模組。如需詳細資訊，請參閱安裝 Azure PowerShell 模組。請記得將和 <your-resource-group-name> 取代<your-storage-account-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 檔案儲存體不直接支援透過QUIC的SMB，但Windows Server 2022 Azure Edition確實支援QUIC通訊協定。您可以使用 Azure 檔案同步，在 Windows Server 2022 Azure 版本 VM 上建立 Azure 檔案共享的羽量型快取。此設定使用埠 443，其已廣泛開放輸出以支援 HTTPS，而不是埠 445。若要深入瞭解此選項，請參閱 SMB over QUIC with Azure 檔案同步。

解決方案 2 - 使用 VPN 或 ExpressRoute藉由將虛擬專用網 (VPN) 或 ExpressRoute 從內部部署設定為您的 Azure 儲存體帳戶，且 Azure 檔案儲存體使用私人端點在您的內部網路上公開，流量將會通過安全通道，而不是透過因特網。請依照指示設定 VPN 以從 Windows 存取 Azure 檔案儲存體。

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

解決方案 4 ：使用 REST API 型工具，例如儲存體總管或 PowerShell Azure 檔案儲存體也支援 REST 以及 SMB。 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 檔案共享時，您可能會收到下列錯誤：

無存取錯誤碼：403

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

原因 1 的解決方案

原因 2：您的使用者帳戶無法存取記憶體帳戶

原因 2 的解決方案

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

檔案鎖定和租用

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

記憶體帳戶資源鎖定：所有 Azure 資源，包括記憶體帳戶，都支援資源鎖定。系統管理員或 Azure 備份等服務可能會將鎖定放在記憶體帳戶上。資源鎖定有兩種變化：修改可防止對記憶體帳戶及其資源進行所有修改，以及刪除，這隻會防止刪除記憶體帳戶及其資源。透過 Microsoft.Storage 資源提供者修改或刪除共享時，會在 Azure 檔案共用和共用快照集上強制執行資源鎖定。大部分的入口網站作業，Azure PowerShell Azure 檔案儲存體的 CmdletRm，其名稱 (例如， Get-AzRmStorageShare) ，以及命令群組中的 share-rm Azure CLI 命令 (例如， az storage share-rm list) 使用Microsoft.Storage資源提供者。某些工具和公用程式，例如儲存體總管、舊版 Azure 檔案儲存體 PowerShell 管理 Cmdlet，不Rm含名稱 (例如， Get-AzStorageShare) ，以及命令群組 (下的share舊版 Azure 檔案儲存體 CLI 命令，例如， az storage share list) 在 FileREST API 中使用略過Microsoft.Storage資源提供者和資源鎖定的舊版 API。如需 FileREST API 中所公開之舊版管理 API 的詳細資訊，請參閱 Azure 檔案儲存體中的控制平面。
共用/共用快照集租用：共用租用是 Azure 檔案共用和檔案共用快照集的一種專屬鎖定。系統管理員可以透過腳本或 Azure 備份等加值服務呼叫 API，將租用放在個別的 Azure 檔案共用或檔案共用快照集上。將租用放在 Azure 檔案共享或檔案共用快照集時，可以使用租用標識碼來修改或刪除檔案共用/共用快照集。系統管理員也可以在需要租用標識符的修改作業之前釋放租用，或中斷租用，而這不需要租用標識符。如需共用租用的詳細資訊，請參閱租用共用。

由於資源鎖定和租用可能會干擾記憶體帳戶/Azure 檔案共用上預期的系統管理員作業，因此您可能想要移除手動或由 Azure 備份等加值服務自動放置在資源上的任何資源鎖定/租用。下列腳本會移除所有資源鎖定和租用。請記得將和 <storage-account> 取代<resource-group>為您環境的適當值。

執行下列腳本之前，您應該先安裝最新版的 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
Linux

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

孤立的檔句柄或租用

檔案共用的其中一個主要用途是多個使用者和應用程式可以同時與共用中的檔案和目錄互動。為了協助進行此互動，檔案共用提供數種方式來媒體存取檔案和目錄。

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

None：您有獨佔存取權。
Read：當您開啟檔案時，其他人可能會讀取該檔案。
Write：其他人可能會在您開啟檔案時寫入檔案。
ReadWrite：和 Write 共用模式的Read組合。
Delete：其他人可能會在您開啟檔案時刪除該檔案。

雖然作為無狀態通訊協定，FileREST 通訊協定沒有檔句柄的概念，但它提供類似的機制來對腳本、應用程式或服務可能使用的檔案和資料夾進行中樞存取：檔案租用。當租用檔案時，它會被視為相當於檔案共用模式為的檔 None句柄。

雖然檔句柄和租用有重要用途，但有時檔句柄和租用可能會遭到孤立。發生這種情況時，這可能會導致修改或刪除檔案時發生問題。您可能會看到如下的錯誤訊息：

進程無法存取檔案，因為檔案正由另一個進程使用。
無法完成動作，因為檔案已在另一個程序中開啟。
檔已鎖定以供其他用戶編輯。
指定的資源會標示為要由SMB客戶端刪除。

此問題的解決方式取決於這是由孤立的檔句柄或租用所造成。

注意事項

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

原因 1

檔句柄會防止修改或刪除檔案/目錄。您可以使用 Get-AzStorageFileHandle PowerShell Cmdlet 來檢視開啟的句柄。

如果所有 SMB 用戶端都已關閉其在檔案/目錄上的開啟句柄，且問題持續發生，您可以強制關閉檔句柄。

解決方案 1

若要強制關閉檔句柄，請使用 Close-AzStorageFileHandle PowerShell Cmdlet。

注意事項

和 Get-AzStorageFileHandleClose-AzStorageFileHandle Cmdlet 包含在 Az PowerShell 模組 2.4 版或更新版本中。若要安裝最新的 Az PowerShell 模組，請參閱安裝 Azure PowerShell 模組。

原因 2

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

# 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 來關閉開啟的句柄。

注意事項

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

原因

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

解決方案

請確定您要以正確的格式傳遞 snapshot 命令的選項 mount 。請參閱 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] 索引標籤。

Windows
Linux

錯誤 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 中，您可能會收到類似下列的錯誤訊息：

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

原因

您已達到檔案或目錄允許的並行開啟句柄上限。

Azure 檔案儲存體支援根目錄上 10,000 個開啟句柄，以及共用內每個檔案和目錄 2,000 個開啟句柄。

解決方案

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

若要檢視檔案共享、目錄或檔案的開啟句柄，請使用 Get-AzStorageFileHandle PowerShell Cmdlet。

若要關閉檔案共享、目錄或檔案的開啟句柄，請使用 Close-AzStorageFileHandle PowerShell Cmdlet。

注意事項

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

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

原因

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

因應措施

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

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

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

Error ConditionHeadersNotSupported from a Web Application using Azure 檔案儲存體 from Browser

透過使用網頁瀏覽器等條件式標頭的應用程式存取 Azure 檔案儲存體裝載的內容時，發生 ConditionHeadersNotSupported 錯誤。錯誤指出不支持條件標頭。

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

原因

尚不支持條件式標頭。每次存取檔案時，實作它們的應用程式都必須要求完整檔案。

因應措施

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

另請參閱

與我們連絡，以取得說明

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

針對SMB) (Azure 檔案儲存體 連線能力和存取問題進行疑難解答

適用於

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

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

原因 1：未加密的通道

原因 1 的解決方案

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

原因 2 的解決方案

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

原因 3 的解決方案

掛接或卸除 Azure 檔案共享時發生錯誤 53、錯誤 67 或錯誤 87

原因 1：埠 445 遭到封鎖

原因 1 的解決方案

原因 2：已啟用 NTLMv1

原因 2 的解決方案

失敗，錯誤碼0x800704b3

原因

解決方案

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

原因

解決方案

「我的電腦」或「此電腦」中沒有具有驅動器號的資料夾

原因

解決方案

如果記憶體帳戶包含正斜線，Net use 命令就會失敗

原因

解決方案

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

原因

解決方案

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

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

當您嘗試存取或刪除 Azure 檔案共享時發生「沒有存取權」錯誤

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

原因 1 的解決方案

原因 2：您的使用者帳戶無法存取記憶體帳戶

原因 2 的解決方案

檔案鎖定和租用

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

孤立的檔句柄或租用

原因 1

解決方案 1

原因 2

解決方案 2

無法在Linux上掛接 Azure 檔案共用快照集

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

原因

解決方案

嘗試在Linux上掛接 Azure 檔案共用快照集時的「錯誤快照集令牌」

原因

解決方案

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

原因

解決方案

太多開啟句柄的磁碟配額或網路錯誤

錯誤 1816 - 沒有足夠的配額可用來處理此命令

原因

解決方案

在句柄上執行任何作業時，ERROR_UNEXP_NET_ERR (59)

原因

解決方案

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

原因

因應措施

Error ConditionHeadersNotSupported from a Web Application using Azure 檔案儲存體 from Browser

原因

因應措施

另請參閱

與我們連絡，以取得說明

意見反應

意見反應

其他資源

針對SMB) (Azure 檔案儲存體連線能力和存取問題進行疑難解答

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