Compartilhar via

Solução de problemas de conectividade e de acesso dos Arquivos do Azure (SMB)

  • Artigo

Este artigo lista problemas comuns que podem ocorrer quando você tenta se conectar e acessar compartilhamentos de arquivos do Azure SMB (Server Message Block) de clientes Windows ou Linux. Também fornece as possíveis causas e resoluções para esses problemas.

Observação

Esse artigo foi útil? Sua opinião é importante para nós. Use o botão Comentários nesta página para nos informar o quão bem este artigo funcionou para você ou como podemos melhorá-lo.

Importante

Este artigo se aplica somente a ações SMB. Para obter detalhes sobre compartilhamentos NFS (Sistema de Arquivos de Rede), consulte Solucionar problemas de compartilhamentos de arquivos NFS do Azure.

Aplica-se a

Tipo de compartilhamento de arquivos SMB NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS

Não é possível se conectar a um compartilhamento de arquivo do Azure nem montá-lo

Selecione a guia Windows ou Linux, dependendo do sistema operacional cliente que você está usando para acessar os compartilhamentos de arquivos do Azure.

Ao tentar se conectar a um compartilhamento de arquivos do Azure no Windows, você poderá ver as mensagens de erro a seguir.

Erro 5 ao montar um compartilhamento de arquivos do Azure

  • Ocorreu um erro de sistema 5. Acesso negado.

Causa 1: Canal de comunicação não criptografado

Por segurança, as conexões para compartilhamentos de arquivos do Azure são bloqueadas se o canal de comunicação não está criptografado, e a tentativa de conexão não é feita do mesmo datacenter onde residem os compartilhamentos de arquivos do Azure. Se a configuração Transferência segura obrigatória estiver habilitada na conta de armazenamento, as conexões não criptografadas no mesmo datacenter também serão bloqueadas. Um canal de comunicação criptografado só é fornecido se o sistema operacional do cliente do usuário final der suporte à criptografia PME.

Windows 8, Windows Server 2012 e versões posteriores de cada sistema negociam solicitações que incluem SMB 3.x, que suporta criptografia.

Solução para a causa 1

  1. Conecte-se em um cliente que dê suporte à criptografia SMB (Windows 8/Windows Server 2012 ou posterior).
  2. Conecte de uma VM (máquina virtual) no mesmo datacenter que a conta de armazenamento do Azure usada para o compartilhamento de arquivos do Azure.
  3. Verifique se a configuração da transferência segura necessária está desabilitada na conta de armazenamento se o cliente não der suporte à criptografia SMB.

Causa 2: rede virtual ou regras de firewall são ativadas na conta de armazenamento

O tráfego de rede é negado se as regras de firewall e de VNET (rede virtual) estão configuradas na conta de armazenamento, a menos que o endereço IP do cliente ou a rede virtual esteja na lista de permitidos.

Solução para a causa 2

Verifique se as regras de firewall e de rede virtual estão configuradas corretamente na conta de armazenamento. Para testar se as regras de firewall ou de rede virtuais estão causando o problema, altere temporariamente a configuração da conta de armazenamento para Permitir o acesso de todas as redes. Para saber mais, confira Configurar redes virtuais e firewalls do Armazenamento do Azure.

Causa 3: permissões de nível de compartilhamento incorretas ao usar a autenticação baseada em identidade

Se os usuários estiverem acessando o compartilhamento de arquivos do Azure usando a autenticação baseada em identidade, o acesso ao compartilhamento de arquivos falhará com o erro "Acesso negado" se as permissões no nível do compartilhamento estiverem incorretas.

Solução para a Causa 3

Valide se as permissões no nível do compartilhamento estão configuradas corretamente. Consulte Atribuir permissões no nível do compartilhamento. As atribuições de permissão em nível de compartilhamento têm suporte para grupos e usuários que foram sincronizados do AD DS para a ID do Microsoft Entra usando o Microsoft Entra Connect Sync ou o Microsoft Entra Connect Cloud Sync. Confirme se os grupos e usuários que recebem permissões no nível do compartilhamento não são grupos "somente na nuvem" sem suporte.

Erro 53, Erro 67 ou Erro 87 ao montar ou desmontar um compartilhamento de arquivos do Azure

Ao tentar montar um compartilhamento de arquivos local ou de um datacenter diferente, você pode receber os seguintes erros:

  • Ocorreu um erro de sistema 53. O caminho da rede não foi encontrado.
  • Ocorreu um erro de sistema 67. O nome de rede não foi encontrado.
  • Ocorreu um erro de sistema 87. O parâmetro está incorreto.

Causa 1: a porta 445 está bloqueada

Pode ocorrer um Erro de sistema 53 ou Erro de sistema 67 se a comunicação de saída na porta 445 para o datacenter de Arquivos do Azure estiver bloqueada. Para ver o resumo de ISPs que permitem ou proíbem o acesso a partir da porta 445, vá para TechNet.

Para verificar se o firewall ou ISP está bloqueando a porta 445, use a ferramenta AzFileDiagnostics ou o cmdlet Test-NetConnection.

Para usar o cmdlet Test-NetConnection, o módulo do Azure PowerShell deve ser instalado. Confira Instalar o módulo do Azure PowerShell para obter mais informações. Lembre-se de substituir <your-storage-account-name> e <your-resource-group-name> pelos nomes referentes a sua conta de armazenamento.

$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

Se a conexão foi bem-sucedida, você verá a seguinte saída:

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

Observação

Esse comando retorna o endereço IP atual da conta de armazenamento. Não há garantia de que esse endereço IP será sempre o mesmo; ele pode mudar a qualquer momento. Não codifique esse endereço IP em nenhum script ou em uma configuração de firewall.

Soluções para a causa 1

Solução 1 – Usar a Sincronização de Arquivos do Azure como um ponto de extremidade QUIC Use a Sincronização de Arquivos do Azure como uma solução alternativa para acessar os Arquivos do Azure em clientes que têm a porta 445 bloqueada. Embora não haja suporte direto ao SMB por QUIC nos Arquivos do Azure, há suporte para o protocolo QUIC no Windows Server 2022 Azure Edition. Você pode criar um cache leve dos compartilhamentos de arquivos do Azure em uma VM do Windows Server 2022 Azure Edition usando a Sincronização de Arquivos do Azure. Essa operação usa a porta 443, que é uma saída amplamente aberta para dar suporte ao HTTPS, em vez da porta 445. Para saber mais sobre essa opção, confira SMB por QUIC com Sincronização de Arquivos do Azure.

Solução 2 – Usar VPN ou ExpressRoute Ao configurar uma VPN (rede virtual privada) ou ExpressRoute do local para sua conta de armazenamento do Azure, com os Arquivos do Azure expostos em sua rede interna usando pontos de extremidade privados, o tráfego passará por um túnel seguro em vez de pela Internet. Siga as instruções para configurar uma VPN para acessar os Arquivos do Azure do Windows.

Solução 3 – Desbloquear a porta 445 com a ajuda do ISP/do administrador de TI Trabalhe com seu departamento de TI ou com o ISP para abrir a porta 445 de saída para os intervalos de IP do Azure.

Solução 4 — Use ferramentas baseadas em API REST, como Gerenciador de Armazenamento ou PowerShell , os Arquivos do Azure também dão suporte a REST, além de SMB. O acesso a REST funciona pela porta 443 (tcp padrão). Há várias ferramentas escritas por meio da API REST que permitem uma experiência sofisticada de interface do usuário. O Gerenciador de Armazenamento é uma delas. Baixe e instale o Gerenciador de Armazenamento e conecte-se ao compartilhamento de arquivo respaldado pelos Arquivos do Azure. Você também pode usar o PowerShell que também usa a API REST.

Causa 2: NTLMv1 está habilitado

O erro de sistema 53 ou erro de sistema 87 também pode ocorrer se a comunicação NTLMv1 está habilitada no cliente. Os Arquivos do Azure dão suporte apenas a autenticação NTLMv2. Ter NTLMv1 habilitado faz com que o cliente esteja menos seguro. Portanto, a comunicação será bloqueada para Arquivos do Azure.

Para determinar se essa é a causa do erro, verifique se a seguinte subchave do registro não está definida com um valor menor que 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Para saber mais, confira o tópico LmCompatibilityLevel no TechNet.

Solução para a causa 2

Reverta o valor LmCompatibilityLevel para o valor padrão de 3 na seguinte subchave do registro:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Falha com o código de erro 0x800704b3

Ao tentar montar um compartilhamento de arquivos do Azure, você recebe o seguinte erro:

Código de erro: 0x800704b3
Nome simbólico: ERROR_NO_NET_OR_BAD_PATH
Descrição do erro: o caminho de rede foi digitado incorretamente, não existe ou o provedor de rede não está disponível no momento. Tente redigitar o caminho ou entre em contato com o administrador da rede.

Motivo

Esse erro pode ocorrer se algum serviço principal relacionado à rede do Windows estiver desabilitado, pois qualquer serviço que dependa explicitamente desses serviços de rede não será iniciado.

Solução

Verifique se algum dos seguintes serviços está em um estado Parado na VM do Windows:

  • Conexões de Rede
  • Serviço da Lista de Redes
  • Reconhecimento de localizações de rede
  • Serviço de interface NSI
  • Cliente DHCP
  • Auxiliar NetBIOS TCP/IP
  • Estação de Trabalho

Se você encontrar algum, inicie os serviços e tente montar novamente o compartilhamento de arquivos do Azure.

O aplicativo ou serviço não pode acessar uma unidade montada dos Arquivos do Azure

Motivo

As unidades são montadas por usuário. Se o seu aplicativo ou o serviço estiver em execução em uma conta de usuário diferente da que montou a unidade, o aplicativo não verá a unidade.

Solução

use uma das seguintes soluções:

  • Monte a unidade a partir da mesma conta de usuário que contém o aplicativo. Você pode usar uma ferramenta como o PsExec.

  • Passe o nome e a chave da conta de armazenamento nos parâmetros de nome de usuário e senha do comando net use.

  • Use o comando cmdkey para adicionar as credenciais no Gerenciador de Credenciais. Execute essa ação em uma linha de comando no contexto da conta de serviço, por meio de um logon interativo ou usando runas.

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

  • Mapeie o compartilhamento diretamente sem usar uma letra de unidade mapeada. Alguns aplicativos podem não se reconectar à letra da unidade corretamente, portanto, usar o caminho UNC completo pode ser mais confiável:

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

Depois de seguir estas instruções, você pode receber a seguinte mensagem de erro quando você executa o net use para a conta de serviço de rede/sistema: "Ocorreu um erro de sistema 1312. Uma sessão de logon especificada não existe. Pode já ter sido encerrado." Se esse erro aparecer, verifique se o nome de usuário para o qual foi passado net use inclui informações de domínio (por exemplo: [storage account name].file.core.windows.net).

Nenhuma pasta com uma letra de unidade em "Meu Computador" ou "Este Computador"

Se você mapear um compartilhamento de arquivo do Azure como administrador usando o comando net use, o compartilhamento parecerá estar ausente.

Causa

Por padrão, o Explorador de Arquivos do Windows não executa como administrador. Se você executar net use em um prompt de comando administrativo, mapeará a unidade de rede como um administrador. Como as unidades mapeadas são centradas no usuário, a conta de usuário conectada não exibirá as unidades se estiverem montadas em uma conta de usuário diferente.

Solução

Monte o compartilhamento de uma linha de comando de não administrador. Como alternativa, você pode seguir este tópico do TechNet para configurar o valor do EnableLinkedConnections Registro.

O comando net use falha se a conta de armazenamento contém uma barra

Causa

O comando net use interpreta uma barra (/) como uma opção de linha de comando. Se o nome da sua conta de usuário começa com uma barra, o mapeamento da unidade falhará.

Solução

Você pode usar qualquer uma das seguintes etapas para contornar o problema:

  • Execute o seguinte comando do PowerShell:

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

    A partir de um arquivo em lotes, você pode executar o comando desta forma:

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

  • Colocando aspas duplas em torno da chave para contornar esse problema, a menos que a barra seja o primeiro caractere. Se for, use o modo interativo e digite sua senha separadamente ou regenere as chaves para obter uma chave que não comece com uma barra.

O comando New-PSDrive falha com o erro "o tipo de recurso de rede não está correto"

Motivo

Você poderá ver essa mensagem de erro se o compartilhamento de arquivos não estiver acessível. Por exemplo, a porta 445 está bloqueada ou há um problema de resolução de DNS.

Solução

Verifique se a porta 445 está aberta e verifique a resolução DNS e a conectividade com o compartilhamento de arquivos.

Não é possível acessar, modificar nem excluir um compartilhamento de arquivo do Azure (ou um instantâneo de compartilhamento)

Erro "O nome de usuário ou senha está incorreto" após um failover iniciado pelo cliente

Em um cenário de failover iniciado pelo cliente com contas de armazenamento com redundância geográfica, os identificadores de arquivo e as concessões não são retidos no failover. Os clientes devem desmontar e remontar os compartilhamentos de arquivos.

Erro "Sem acesso" durante a tentativa de acessar ou excluir um compartilhamento de arquivo do Azure

Ao tentar acessar ou excluir um compartilhamento de arquivo do Azure usando o portal do Azure, você poderá receber o seguinte erro:

Sem acesso Código de erro: 403

Causa 1: rede virtual ou regras de firewall são habilitadas na conta de armazenamento

Solução para a Causa 1

Verifique se as regras de firewall e de rede virtual estão configuradas corretamente na conta de armazenamento. Para testar se as regras de firewall ou de rede virtual estão causando o problema, altere temporariamente a configuração da conta de armazenamento para Permitir o acesso em todas as redes. Para saber mais, confira Configurar redes virtuais e firewalls do Armazenamento do Azure.

Causa 2: sua conta de usuário não tem acesso à conta de armazenamento

Solução para a causa 2

Navegue até a conta de armazenamento na qual o compartilhamento de arquivos do Azure está localizado, selecione Controle de acesso (IAM) e verifique se sua conta de usuário tem acesso à conta de armazenamento. Para saber mais, confira Como proteger a conta de armazenamento com o RBAC (Controle de Acesso Baseado em Função) do Azure.

Bloqueios de arquivo e concessões

Se você não puder modificar nem excluir um instantâneo ou um compartilhamento de arquivo do Azure, isso poderá ser devido a bloqueios de arquivo ou concessões. Os Arquivos do Azure fornecem duas maneiras de evitar a modificação acidental ou a exclusão de compartilhamentos de arquivos do Azure e instantâneos de compartilhamento:

  • Bloqueios de recurso da conta de armazenamento: há suporte para bloqueios de recurso em todos os recursos do Azure, incluindo a conta de armazenamento. Os bloqueios podem ser colocados na conta de armazenamento por um administrador ou por serviços como o Backup do Azure. Existem duas variações de bloqueios de recursos: modify, que impede todas as modificações na conta de armazenamento e seus recursos, e delete, que impede apenas exclusões da conta de armazenamento e seus recursos. Ao modificar ou excluir compartilhamentos por meio do provedor de recursos Microsoft.Storage, os bloqueios de recursos são impostos em compartilhamentos de arquivos e instantâneos de compartilhamento do Azure. A maioria das operações do portal, cmdlets do Azure PowerShell para Arquivos do Azure com Rm no nome (por exemplo, Get-AzRmStorageShare) e comandos da CLI do share-rm Azure no grupo de comandos (por exemplo, az storage share-rm list) usam o Microsoft.Storage provedor de recursos. Algumas ferramentas e utilitários, como o Gerenciador de Armazenamento, cmdlets de gerenciamento herdados do PowerShell dos Arquivos do Azure sem Rm no nome (por exemplo, Get-AzStorageShare) e comandos herdados da CLI dos share Arquivos do Azure no grupo de comandos (por exemplo, az storage share list) usam APIs herdadas na API FileREST que ignoram o provedor de recursos e os Microsoft.Storage bloqueios de recursos. Para obter mais informações sobre APIs de gerenciamento herdado expostas na API FileREST, consulte plano de controle no Arquivos do Azure.

  • Concessões de instantâneo de compartilhamento/compartilhamento: as concessões de compartilhamento são um tipo de bloqueio proprietário para compartilhamentos de arquivos do Azure e instantâneos de compartilhamento de arquivos. As concessões podem ser colocadas em compartilhamentos de arquivos individuais do Azure ou instantâneos de compartilhamento de arquivos pelos administradores chamando a API por meio de um script ou por serviços de valor agregado, como o Backup do Azure. Quando uma concessão é colocada em um instantâneo de compartilhamento de arquivos ou compartilhamento de arquivos do Azure, modificar ou excluir o instantâneo de compartilhamento/compartilhamento de arquivos pode ser feito com a ID de concessão. Os administradores também podem liberar a concessão antes das operações de modificação, o que requer a ID da concessão, ou interromper a concessão, o que não requer a ID da concessão. Para obter mais informações sobre concessões de compartilhamento, consulte compartilhamento de concessão.

Como os bloqueios de recursos e as concessões podem interferir nas operações de administrador pretendidas na sua conta de armazenamento/nos compartilhamentos de arquivos do Azure, o ideal é remover os bloqueios de recursos/as concessões que possam ter sido colocados nos seus recursos manual ou automaticamente por serviços com valor agregado, como o Backup do Azure. O script a seguir remove todos os bloqueios de recursos e as concessões. Não deixe de substituir <resource-group> e <storage-account> pelos valores adequados para seu ambiente.

Antes de executar o script a seguir, você deve instalar a última versão do módulo do PowerShell para o Armazenamento do Azure.

Importante

Serviços com valor agregado que levam bloqueios de recursos e compartilham/compartilham concessões de instantâneo em seus recursos de Arquivos do Azure podem reaplicar periodicamente bloqueios e concessões. Modificar ou excluir recursos bloqueados por serviços de valor agregado pode afetar a operação regular desses serviços, como excluir instantâneos de compartilhamento gerenciados pelo Backup do 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 { }
    }

Não é possível modificar, mover/renomear ou excluir um arquivo ou diretório

Selecione a guia Windows ou Linux, dependendo do sistema operacional cliente que você está usando para acessar os compartilhamentos de arquivos do Azure.

No Windows, talvez você veja os erros a seguir.

Identificadores de arquivo órfão ou concessões

Uma das principais finalidades de um compartilhamento de arquivos é que vários usuários e aplicativos podem interagir simultaneamente com arquivos e diretórios no compartilhamento. Para ajudar nessa interação, os compartilhamentos de arquivos fornecem várias maneiras de mediar o acesso a arquivos e diretórios.

Quando você abre um arquivo de um compartilhamento de arquivos do Azure montado em SMB, seu aplicativo/sistema operacional solicita um identificador de arquivo, que é uma referência ao arquivo. Entre outras coisas, seu aplicativo especifica um modo de compartilhamento de arquivos quando solicita um identificador de arquivo, que especifica o nível de exclusividade do seu acesso ao arquivo imposto pelos Arquivos do Azure:

  • None: você tem acesso exclusivo.
  • Read: outras pessoas podem ler o arquivo enquanto ele estiver aberto.
  • Write: outras pessoas podem gravar no arquivo enquanto ele estiver aberto.
  • ReadWrite: uma combinação dos modos de compartilhamento Read e Write.
  • Delete: outras pessoas podem excluir o arquivo enquanto ele estiver aberto.

Embora seja um protocolo sem estado, o protocolo FileREST não possui um conceito de identificadores de arquivo, ele fornecerá um mecanismo semelhante para mediar o acesso a arquivos e pastas que o script, aplicativo ou serviço poderá usar: concessões de arquivos. Quando um arquivo for concedido, será tratado como equivalente a um identificador de arquivo com um modo de compartilhamento de arquivos de None.

Embora os identificadores de arquivo e as concessões sirvam um objetivo importante, às vezes, eles podem se tornar órfãos. Quando isso acontece, pode causar problemas na modificação ou na exclusão de arquivos. Você poderá ver mensagens de erro como:

  • O processo não pode acessar o arquivo porque ele está sendo usado por outro processo.
  • A ação não pode ser concluída porque o arquivo está aberto em outro programa.
  • O documento está bloqueado para edição por outro usuário.
  • O recurso especificado está marcado para exclusão por um cliente SMB.

A resolução desse problema depende de se isso está sendo causado por concessão ou identificador de arquivo órfão.

Observação

As concessões REST são usadas por aplicativos para impedir que arquivos sejam excluídos ou modificados. Antes de interromper qualquer concessão, você deve identificar qual aplicativo as está adquirindo. Caso contrário, você pode interromper o comportamento do aplicativo.

Causa 1

Um identificador de arquivo está impedindo um arquivo/diretório de ser modificado ou excluído. Você pode usar o cmdlet Get-AzStorageFileHandle do PowerShell para exibir identificadores abertos.

Se todos os clientes SMB tiverem fechado seus identificadores abertos em um arquivo/diretório e o problema continuar a ocorrer, você poderá forçar o fechamento de um identificador de arquivo.

Solução 1

Para forçar o fechamento de um identificador de arquivo, use o cmdlet Close-AzStorageFileHandle do PowerShell.

Observação

Os cmdlets Get-AzStorageFileHandle e Close-AzStorageFileHandle estão incluídos no módulo Az PowerShell versão 2.4 ou posterior. Para instalar o módulo Az PowerShell mais recente, confira Instalar o módulo Azure PowerShell.

Causa 2

Uma concessão de arquivo impede que um arquivo seja modificado ou excluído. Você pode verificar se um arquivo tem uma concessão de arquivo com os seguintes comandos do PowerShell. Substitua <resource-group>, <storage-account>, <file-share> e <path-to-file> pelos valores adequados de acordo com o seu ambiente.

# 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

Se um arquivo tiver uma concessão, o objeto retornado deverá conter as seguintes propriedades:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Solução 2

Para remover uma concessão de um arquivo, você pode liberar ou interromper a concessão. Para liberar a concessão, você precisa da LeaseId da concessão, que você define ao criar a concessão. Você não precisa da LeaseId para interromper a concessão.

O exemplo a seguir mostra como quebrar a concessão para o arquivo indicado na causa 2 (este exemplo continua com as variáveis do PowerShell da causa 2):

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

Não é possível montar um instantâneo do compartilhamento de arquivo do Azure no Linux

"Erro de montagem(22): argumento inválido" durante a tentativa de montar um instantâneo de compartilhamento de arquivo do Azure no Linux

Causa

Se a opção snapshot para o comando mount não for transmitida em um formato reconhecido, o comando mount poderá falhar com esse erro. Para confirmá-lo, verifique as mensagens de log do kernel (dmesg) e o dmesg mostrará uma entrada de log como cifs: Bad value for 'snapshot'.

Solução

Verifique se você está transmitindo a opção snapshot para o comando mount no formato correto. Veja a página de manual mount.cifs (por exemplo, man mount.cifs). Um erro comum é transmitir o carimbo de data/hora GMT no formato errado, como usar hífen ou dois-pontos no lugar do ponto final. Para obter mais informações, confira Montar um instantâneo de compartilhamento de arquivo.

"Token de instantâneo inválido" durante a tentativa de montar um instantâneo de compartilhamento de arquivo do Azure no Linux

Causa

Se a opção de instantâneo mount for transmitida começando com @GMT, mas o formato ainda estiver errado (como o uso de hífen e dois-pontos em vez de ponto final), o comando mount poderá falhar com esse erro.

Solução

Certifique-se de que está a transmitir o carimbo de data/hora GMT no formato correto, que é @GMT-year.month.day-hour.minutes.seconds. Para obter mais informações, confira Montar um instantâneo de compartilhamento de arquivo.

"Erro de montagem(2): nenhum arquivo ou diretório desse tipo" durante a tentativa de montar um instantâneo de compartilhamento de arquivo do Azure

Motivo

Se o snapshot que você está tentando montar não existir, o mount comando poderá falhar com esse erro. Para confirmar, verifique as mensagens de log do kernel (dmesg) e o dmesg mostrará uma entrada de log como:

[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

Solução

Verifique se o instantâneo que você está tentando montar existe. Para obter mais informações sobre como listar os instantâneos disponíveis para determinado compartilhamento de arquivo do Azure, confira Montar um instantâneo de compartilhamento de arquivo.

Erros de rede ou de cota de disco de muitos identificadores abertos

Selecione a guia Windows ou Linux, dependendo do sistema operacional cliente que você está usando para acessar os compartilhamentos de arquivos do Azure.

Erro 1816 - Não há cota suficiente para processar este comando

Causa

O Erro 1816 ocorre quando você atingir o limite superior de identificadores abertos simultâneos permitidos para um arquivo ou diretório no compartilhamento de arquivos do Azure. Para obter mais informações, confira Destinos de escala de Arquivos do Azure.

Solução

Reduza o número de identificadores abertos simultâneos fechando alguns identificadores e tentando novamente. Para obter mais informações, consulte Lista de verificação de desempenho e escalabilidade do Armazenamento do Microsoft Azure.

Para exibir os identificadores abertos para um compartilhamento de arquivo, diretório ou arquivo, use o cmdlet do PowerShell Get-AzStorageFileHandle.

Para fechar os identificadores abertos de um compartilhamento de arquivo, diretório ou arquivo, use o cmdlet do PowerShell Close-AzStorageFileHandle.

Observação

Os cmdlets Get-AzStorageFileHandle e Close-AzStorageFileHandle estão incluídos no módulo Az PowerShell versão 2.4 ou posterior. Para instalar o módulo Az PowerShell mais recente, confira Instalar o módulo Azure PowerShell.

ERROR_UNEXP_NET_ERR (59) ao fazer qualquer operação em um identificador

Causa

Se você manter/armazenar em cache um grande número de identificadores abertos por um longo tempo, poderá ver essa falha do lado do servidor devido a motivos de limitação. Quando um grande número de identificadores for armazenado em cache pelo cliente, muitos desses identificadores poderão entrar em uma fase de reconexão ao mesmo tempo, criando uma fila no servidor que precisará ser limitada. A lógica de repetição e a limitação no back-end para reconexão demoram mais do que o tempo limite do cliente. Esta situação se manifestará como um cliente que não pode usar um identificador existente para qualquer operação, com todas as operações falhando com ERROR_UNEXP_NET_ERR (59).

Há também casos extremos em que o identificador do cliente é desconectado do servidor (por exemplo, uma interrupção de rede com duração de vários minutos) que poderá causar esse erro.

Solução

Não mantenha um grande número de identificadores armazenados em cache. Feche as alças e tente novamente. Use os cmdlets Get-AzStorageFileHandle e Close-AzStorageFileHandle do PowerShell para ver/fechar os identificadores abertos.

Se você estiver usando compartilhamentos de arquivos do Azure para armazenar contêineres de perfil ou imagens de disco para uma implantação de área de trabalho virtual em larga escala ou outras cargas de trabalho que abrem identificadores em arquivos, diretórios e/ou no diretório raiz, poderá atingir os limites superiores de escala para identificadores abertos simultâneos. Nesse caso, use um compartilhamento de arquivos adicional do Azure e distribua os contêineres ou imagens entre os compartilhamentos.

Erro "Você está copiando um arquivo para um destino que não dá suporte à criptografia"

Quando um arquivo é copiado pela rede, o arquivo é descriptografado no computador de origem, transmitido em texto não criptografado e criptografado novamente no destino. No entanto, você pode ver o seguinte erro quando estiver tentando copiar um arquivo criptografado: "Você está copiando o arquivo para um destino que não dá suporte à criptografia".

Causa

Esse problema pode ocorrer se você estiver usando o sistema de arquivos com criptografia (EFS). Os arquivos criptografados pelo BitLocker podem ser copiados para os Arquivos do Azure. No entanto, os Arquivos do Azure não dão suporte a EFS NTFS.

Solução alternativa

Para copiar um arquivo pela rede, você deve primeiro descriptografá-lo. Use um dos métodos a seguir:

  • Use o comando copy /d. Ele permite que os arquivos criptografados sejam salvos como arquivos descriptografados no destino.
  • Defina a seguinte chave do Registro:
    • Caminho = HKLM\Software\Policies\Microsoft\Windows\System
    • Tipo de valor = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Value = 1

Observe que a definição da chave do registro afeta todas as operações de cópia que são feitas para compartilhamentos de rede.

Erro ConditionHeadersNotSupported de um aplicativo Web usando arquivos do Azure do navegador

O erro ConditionHeadersNotSupported ocorre ao acessar o conteúdo hospedado nos Arquivos do Azure por meio de um aplicativo que usa cabeçalhos condicionais, como um navegador da Web, o acesso falha. O erro indica que não há suporte para cabeçalhos de condição.

Captura de tela que mostra a mensagem de erro ConditionHeadersNotSupported.

Motivo

Ainda não há suporte para cabeçalhos condicionais. Os aplicativos que os implementam precisarão solicitar o arquivo completo sempre que o arquivo for acessado.

Solução alternativa

Quando um novo arquivo é carregado, a propriedade CacheControl por padrão é no-cache. Para forçar o aplicativo a solicitar o arquivo todas as vezes, a propriedade CacheControl do arquivo precisa ser atualizada de no-cache para no-cache, no-store, must-revalidate. Isso pode ser feito usando o Gerenciador de Armazenamento do Azure.

Screeshot que mostra a propriedade do arquivo CacheControl.

Confira também

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.