通过

排查 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：使用基于标识的身份验证时，共享级别权限不正确

如果用户使用基于标识的身份验证访问 Azure 文件共享，则如果共享级别权限不正确，则对文件共享的访问失败，并出现“拒绝访问”错误。

原因 3 的解决方案

验证是否已正确配置共享级别权限。 请参阅 “分配共享级别权限”。 已使用 Microsoft Entra Connect 同步或Microsoft Entra Connect 云同步，已从 AD DS 同步到 Microsoft Entra ID 的组和用户支持共享级权限分配。确认分配的组和用户不受支持的“仅限云”组。

尝试装载或卸载 Azure 文件共享时发生错误 53、错误 67 或错误 87

尝试从本地或其他数据中心装载文件共享时，可能会收到以下错误：

  • 发生系统错误 53。 找不到网络路径。
  • 发生系统错误 67。 找不到网络名称。
  • 发生系统错误 87。 参数不正确。

原因 1：端口 445 被阻止

如果端口 445 到 Azure 文件存储数据中心的出站通信受阻，可能会出现系统错误 53 或 67。 如需大致了解允许或禁止从端口 445 进行访问的 ISP，请访问 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 文件存储，流量将通过安全隧道而不是通过 Internet。 按照说明设置 VPN 以从 Windows 访问Azure 文件存储。

解决方案 3 - 在 ISP/IT 管理员的帮助下取消阻止端口 445 请与 IT 部门或 ISP 协作以打开指向 Azure IP 范围的端口 445 出站。

解决方案 4 - 除了 SMB 之外，还支持基于 REST API 的工具，例如存储资源管理器或 PowerShell Azure 文件存储。 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 资源（包括存储帐户）都支持资源锁。 管理员或服务（如Azure 备份）可能会锁定存储帐户。 存在两种资源锁变体： 修改，这会阻止对存储帐户及其资源进行所有修改，并 删除，这只会阻止删除存储帐户及其资源。 通过 Microsoft.Storage 资源提供程序修改或删除共享时，将在 Azure 文件共享和共享快照上强制实施资源锁。 大多数门户操作、用于Azure 文件存储Rm的 Azure PowerShell cmdlet 的名称（例如Get-AzRmStorageShare）和命令组中的 Azure CLI 命令share-rm（例如）az storage share-rm list使用Microsoft.Storage资源提供程序。 某些工具和实用工具（例如，存储资源管理器、旧版Azure 文件存储 PowerShell 管理 cmdlet）的名称Rm（例如Get-AzStorageShare）和命令组下的share旧版 Azure 文件存储 CLI 命令（例如az storage share list）在 FileREST API 中使用旧 API，绕过Microsoft.Storage资源提供程序和资源锁。 有关 FileREST API 中公开的旧管理 API 的详细信息，请参阅 Azure 文件存储中的控制平面。

  • 共享/共享快照租约：共享租约是用于 Azure 文件共享和文件共享快照的一种专有锁。 通过脚本或增值服务（如Azure 备份）调用 API，管理员可以将租约放置在单个 Azure 文件共享或文件共享快照上。 将租约置于 Azure 文件共享或文件共享快照上时，可以使用租约 ID 修改或删除文件共享/共享快照。 管理员还可以在修改操作之前释放租约，这需要租约 ID 或中断租约，这不需要租约 ID。 有关共享租约的详细信息，请参阅租约共享。

由于资源锁和租约可能会干扰对存储帐户/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。

注意

Get-AzStorageFileHandle 和 Close-AzStorageFileHandle cmdlet 包含在 Az PowerShell 模块 2.4 或更高版本中。 若要安装最新 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 文件共享快照时出现“快照令牌错误”

原因

如果传递快照 mount 选项时以 @GMT 开头，但格式仍然错误（例如使用连字符和冒号而非句点），则 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 - 处理此命令的配额不够

原因

达到并发开放句柄数的上限时，会发生错误 1816。这些句柄是为 Azure 文件共享上的文件或目录启用的。 有关详细信息，请参阅 Azure 文件规模目标。

解决方案

关闭一些句柄，减少并发打开句柄的数量，再重试。 有关详细信息，请参阅 Microsoft Azure 存储性能和可伸缩性清单。

若要查看文件共享、目录或文件的打开句柄，请使用 Get-AzStorageFileHandle PowerShell cmdlet。

若要关闭文件共享、目录或文件的打开句柄，请使用 Close-AzStorageFileHandle PowerShell cmdlet。

注意

Get-AzStorageFileHandle 和 Close-AzStorageFileHandle cmdlet 包含在 Az PowerShell 模块 2.4 或更高版本中。 若要安装最新 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 命令。 这样，可以将加密文件作为解密文件保存到目标位置。
  • 设置以下注册表项：
    • Path = HKLM\Software\Policies\Microsoft\Windows\System
    • Value type = DWORD
    • 名称 = CopyFileAllowDecryptedRemoteDestination
    • 值 = 1

请注意，设置注册表项会影响对网络共享进行的所有复制操作。

从浏览器访问使用 Azure 文件存储的 Web 应用程序时出现错误 ConditionHeadersNotSupported

通过使用条件标头的应用程序（例如 Web 浏览器）访问 Azure 文件存储中托管的内容时，将发生 ConditionHeadersNotSupported 错误，访问失败。 错误指出不支持条件标头。

显示 ConditionHeadersNotSupported 错误消息的屏幕截图。

原因

尚不支持条件标头。 实现它们的应用程序将需要在每次访问文件时请求完整的文件。

解决方法

上传新文件时， 默认情况下 CacheControl 属性为 无缓存。 若要强制应用程序每次请求文件，需要将文件的 CacheControl 属性从 no-cache 更新为 no-cache、no-store、must-revalidate。 这可以使用 Azure 存储资源管理器来实现。

显示 CacheControl 文件属性的 Screeshot。

另请参阅

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。