Solucionar problemas dos Arquivos do Azure no Linux (SMB)

  • Artigo
  • 19 minutos para o fim da leitura

Este artigo lista os problemas comuns relacionados aos compartilhamentos de arquivo do Azure SMB, ao se conectar em clientes Linux. Também fornece as possíveis causas e resoluções para esses problemas.

Além das etapas de solução de problemas deste artigo, você pode usar AzFileDiagnostics para garantir que o cliente Linux tenha pré-requisitos corretos. O AzFileDiagnostics automatiza a detecção da maioria dos sintomas mencionados neste artigo. Isso ajuda a configurar seu ambiente para obter um desempenho ideal. Você também pode encontrar essas informações na solução de problemas de compartilhamentos de arquivo do Azure. A solução de problemas fornece etapas para ajudá-lo com problemas de conexão, o mapeamento e montar os compartilhamentos de arquivo do Azure.

Importante

O conteúdo deste artigo se aplica somente a compartilhamentos SMB. Para obter detalhes sobre compartilhamentos NFS, confira Solucionar problemas de compartilhamentos de arquivo do Azure NFS.

Aplica-se a

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

Não é possível se conectar a ou montar um compartilhamento de arquivos do Azure

Causa

Causas comuns para esse problema são:

  • Você está usando uma distribuição do Linux com um cliente do SMB desatualizado. Confira Usar o Arquivos do Azure com o Linux, para obter mais informações sobre as distribuições comuns do Linux disponíveis no Azure com clientes compatíveis.
  • Os utilitários SMB (cifs-utils) não estão instalados no cliente.
  • A versão mínima do SMB, 2.1, não está instalada no cliente.
  • Não há suporte para a criptografia SMB 3.x no cliente. A tabela anterior fornece uma lista de distribuições do Linux que dão suporte à montagem a partir do local e entre regiões usando criptografia. Outras distribuições requerem o kernel 4.11 e versões posteriores.
  • Você está tentando se conectar a um compartilhamento de arquivo do Azure em uma VM do Azure, e a VM não está na mesma região da conta de armazenamento.
  • Se a configuração Transferência segura necessária estiver ativada na conta de armazenamento, os Arquivos do Azure só permitirão conexões que usem o SMB 3.x com criptografia.

Solução

Para resolver o problema, use o ferramenta de solução de problemas para os arquivos do Azure erros de montagem no Linux. Essa ferramenta:

  • Ajuda a validar o ambiente de execução de cliente.
  • Detecta a configuração de cliente incompatível que causaria falha de acesso para arquivos do Azure.
  • Dá orientação prescritiva sobre auto-fixação.
  • Coleta os rastreamentos de diagnóstico.

“Erro de montagem(13): permissão negada” quando você monta um compartilhamento de arquivos do Azure

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

Por motivos de 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. As conexões não criptografadas dentro do mesmo datacenter também podem ser bloqueadas se o transferência segura obrigatória está habilitada na conta de armazenamento. Um canal de comunicação criptografado é fornecido somente quando o sistema operacional do cliente do usuário dá suporte à criptografia SMB.

Para saber mais, confira Pré-requisitos para montar um compartilhamento de arquivos do Azure com o Linux e o pacote cifs-utils.

Solução para a causa 1

  1. Conecte-se de um cliente com suporte à criptografia SMB ou conecte a partir de uma máquina virtual que está no mesmo datacenter da conta de armazenamento do Azure usada para o compartilhamento de arquivos do Azure.
  2. Verifique se a configuração Transferência segura obrigatória está desabilitada na conta de armazenamento se o cliente não oferecer suporte à criptografia SMB.

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

Se as regras de firewall e de VNET (rede virtual) estiverem configuradas na conta de armazenamento, o tráfego de rede terá acesso negado a menos que o endereço IP do cliente ou da rede virtual tenha permissão de acesso.

Solução para a causa 2

Verifique se 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.

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

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 confirmar isso, verifique se as mensagens de log do kernel (dmesg) e o dmesg mostrarão uma entrada de log, como cifs: Valor inválido para '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

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

Verifique se você está transmitindo 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

Causa

Se o instantâneo que você está tentando montar não existir, o comando mount poderá falhar com esse erro. Para confirmar isso, verifique se as mensagens de log do kernel (dmesg) e o dmesg mostrarão 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.

“[permissão negada] Cota de disco excedida” ao tentar abrir um arquivo

No Linux, você recebe uma mensagem de erro semelhante à seguinte:

<nome do arquivo> [permissão negada] Cota de disco excedida

Causa

Você atingiu o limite máximo de identificadores abertos simultâneos permitidos para um arquivo ou diretório.

Há uma cota de 2.000 identificadores abertos em um único arquivo ou diretório. Quando você tem 2.000 identificadores abertos, uma mensagem de erro é exibida informando que a cota foi atingida.

Solução

Reduza o número de identificadores abertos simultâneos fechando alguns deles e repita a operação.

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.

Cópia de arquivos bidirecional lenta dos Arquivos do Azure no Linux

  • Se você não tiver um requisito mínimo de tamanho de E / S específico, recomendamos usar 1 MiB como o tamanho de E / S para um desempenho ideal.
  • Use o método de cópia correto:
    • Use o AzCopy para todas as transferências entre dois compartilhamentos de arquivo.
    • Usar cp ou dd com parallel pode melhorar a velocidade de cópia, o número de threads depende do seu caso de uso e carga de trabalho. Os seguintes exemplos usam seis:
    • Exemplo de cp (cp usará o tamanho de bloco padrão do sistema de arquivos como o tamanho da parte): find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ &.
    • Exemplo de dd (este comando define explicitamente o tamanho da parte para 1 MiB): find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
    • Ferramentas de terceiros de software livre, como:
      • GNU Parallel.
      • Fpart ꟷ classifica os arquivos e os compacta em partições.
      • Fpsync ꟷ usa fpart e uma ferramenta de cópia para gerar várias instâncias para migrar dados de src_dir para dst_url.
      • Multi ꟷ cp e md5sum com vários threads com base em coreutils do GNU.
  • Definir o tamanho do arquivo com antecedência, em vez de tornar cada gravação uma gravação extensiva, ajuda a melhorar a velocidade de cópia em cenários em que o tamanho do arquivo é conhecido. Se for necessário evitar a extensão de gravações, você poderá definir um tamanho de arquivo de destino com o comando truncate --size <size> <file>. Depois disso, o comando dd if=<source> of=<target> bs=1M conv=notrunc copiará um arquivo de origem sem ter que atualizar repetidamente o tamanho do arquivo de destino. Por exemplo, você pode definir o tamanho do arquivo de destino para cada arquivo que deseja copiar (suponha que um compartilhamento seja montado em /mnt/share):
    • for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done
    • e, em seguida, copie os arquivos sem estender as gravações em parallel: find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

“Erro de montagem (115): operação em andamento” durante a montagem dos Arquivos do Azure usando o SMB 3.x

Causa

Algumas distribuições de Linux ainda não suportam recursos de criptografia no SMB 3.x. Os usuários podem receber uma mensagem de erro "115" se tentarem montar Arquivos do Azure usando o SMB 3.x devido a um recurso ausente. O SMB 3.x com criptografia total é suportado apenas ao utilizar o Ubuntu 16.04 ou posterior.

Solução

O recurso de criptografia para SMB 3.x para Linux foi introduzido no kernel 4.11. Esse recurso permite a montagem de um compartilhamento de arquivos do Azure de local ou de uma região diferente do Azure. Algumas distribuições do Linux podem ter feito backport do kernel 4.11 para versões mais antigas do kernel do Linux que eles mantêm. Para ajudar a determinar se sua versão do Linux oferece suporte a SMB 3.x com criptografia, consulte Usar Arquivos do Azure com Linux.

Se o seu cliente SMB do Linux não oferecer suporte à criptografia, monte os arquivos do Azure usando o SMB 2.1 de uma VM do Azure Linux que esteja no mesmo datacenter do compartilhamento de arquivos. Verifique se a configuração Transferência segura necessária está desativada na conta de armazenamento.

Erro "Sem acesso" ao tentar acessar ou excluir um compartilhamento de arquivos do Azure

Ao tentar acessar ou excluir um compartilhamento de arquivos do Azure no portal, você pode 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 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 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 onde o compartilhamento de arquivos do Azure está localizado, clique em 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.

Não é possível excluir um arquivo ou diretório em um compartilhamento de arquivos do Azure

Causa

Esse problema normalmente ocorre caso o arquivo ou diretório tenha um identificador aberto.

Solução

Se os clientes SMB tiverem fechado todos os identificadores abertos e o problema persistir, faça o seguinte:

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.

Desempenho lento em um compartilhamento de arquivos do Azure montado em uma VM Linux

Causa 1: cache

Uma possível causa da lentidão no desempenho é o cache desabilitado. O cache pode ser útil se você estiver acessando um arquivo repetidamente; caso contrário, pode ser uma sobrecarga. Verifique se você está usando o cache antes de desabilitá-lo.

Solução para a causa 1

Para verificar se o cache está desabilitado, procure a entrada cache=.

Cache=none indica que o cache está desabilitado. Remonte o compartilhamento usando o comando de montagem padrão ou adicionando explicitamente a opção cache=strict ao comando de montagem para garantir que o modo de cache padrão ou de cache “strict” seja habilitado.

Em alguns cenários, a opção de montagem serverino pode fazer com que o comando ls execute stat em cada entrada do diretório. Esse comportamento resulta na degradação do desempenho quando você está listando um diretório grande. Verifique as opções de montagem na entrada /etc/fstab:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Você também pode verificar se as opções corretas estão sendo usadas executando o comando sudo mount | grep cifs e verificando a saída. A seguir está a saída de exemplo:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Se a opção cache=strict ou serverino não estiver presente, desmonte e monte os Arquivos do Azure novamente executando o comando de montagem da documentação. Em seguida, verifique novamente se a entrada /etc/fstab tem as opções corretas.

Causa 2: limitação

É possível que você esteja enfrentando limitação e suas solicitações estejam sendo enviadas para uma fila. Você pode verificar isso aproveitando as Métricas de armazenamento do Azure no Azure Monitor.

Solução para a causa 2

Verifique se o seu aplicativo está dentro dos destinos de escala dos Arquivos do Azure.

Os carimbos de data/hora foram perdidos durante a cópia de arquivos do Windows para o Linux

Em plataformas Linux / Unix, o comando cp -p falha se usuários diferentes possuírem o arquivo 1 e o arquivo 2.

Causa

O sinalizador de força f em COPYFILE resulta na execução de cp -p -f no Unix. Esse comando também não preserva o carimbo de data/hora do arquivo que você não possui.

Solução alternativa

Use o usuário da conta de armazenamento para copiar os arquivos:

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls: não é possível acessar '<caminho>': erro de entrada/saída

Quando você tenta listar arquivos em um compartilhamento de arquivos do Azure usando o comando ls, o comando trava ao listar arquivos. Você obterá o seguinte erro:

ls: não é possível acessar '<caminho>': erro de entrada/saída

Solução

Atualize o kernel do Linux para as seguintes versões que possuem uma correção para esse problema:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Todas as versões que são maiores ou iguais a 4,13

Não é possível criar links simbólicos - ln: falhou ao criar link simbólico 't': Operação não suportada

Causa

Por padrão, a montagem de compartilhamentos de arquivos do Azure no Linux usando o CIFS não habilita a compatibilidade com links simbólicos (links simbólicos). Você verá um erro como este:

ln -s linked -n t
ln: failed to create symbolic link 't': Operation not supported

Solução

O cliente CIFS do Linux não é compatível com a criação de links simbólicos no estilo do Windows sobre o protocolo SMB 2 ou 3. Atualmente, o cliente Linux suporta outro estilo de links simbólicos chamado Minshall + francês symlinks para criar e seguir operações. Os clientes que precisam de links simbólicos podem usar a opção de montagem "mfsymlinks". Recomendamos "mfsymlinks" porque também é o formato que os Macs usam.

Para usar links simbólicos, adicione o seguinte ao final do seu comando de montagem CIFS:

,mfsymlinks

Então o comando parece algo como:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

Em seguida, você pode criar links simbólicos como sugerido na wiki.

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 os cabeçalhos de condição não são suportados.

Erro nos cabeçalhos condicionais dos arquivos do Azure

Causa

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 cache-control por padrão é “no-cache”. Para forçar o aplicativo a solicitar o arquivo todas as vezes, a propriedade cache-control 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.

Modificação do cache de conteúdo do explorador de armazenamento para cabeçalhos condicionais de Arquivos do Azure

“Erro de montagem (112): o host está inativo” devido a um tempo limite de reconexão

Um erro de montagem “112” ocorre no cliente Linux quando o cliente ficou ocioso por um longo período. Após um tempo ocioso estendido, o cliente se desconecta e a conexão atinge o tempo limite.

Causa

A conexão pode ficar ociosa pelos seguintes motivos:

  • Falhas de comunicação de rede que impedem o restabelecimento de uma conexão TCP com o servidor quando a opção de montagem "soft" padrão é usada
  • Correções de reconexão recentes que não estão presentes nos kernels mais antigos

Solução

Esse problema de reconexão no kernel do Linux agora foi corrigido como parte das seguintes alterações:

No entanto, essas alterações ainda podem não ter sido portadas para todas as distribuições do Linux. Se estiver usando uma distribuição popular do Linux, você poderá verificar em Usar Arquivos do Azure com Linux qual versão da sua distribuição tem as alterações de kernel necessárias.

Solução alternativa

Resolva esse problema especificando uma montagem rígida. Uma montagem rígida força o cliente a esperar até que uma conexão seja estabelecida ou até que seja explicitamente interrompida. Você pode usá-lo para evitar erros devido a tempos limite da rede. No entanto, essa solução alternativa pode causar esperas indefinidas. Esteja preparado para interromper conexões, conforme necessário.

Se você não pode atualizar para as versões mais recentes do kernel, você pode contornar esse problema mantendo um arquivo no compartilhamento de arquivos do Azure que você grava a cada 30 segundos ou menos. Essa deve ser uma operação de gravação, como regravar a data de criação ou de modificação no arquivo. Caso contrário, você poderá obter resultados em cache e a operação poderá não disparar a reconexão.

"CIFS VFS: erro -22 no ioctl para obter lista de interface" ao montar um compartilhamento de arquivo do Azure usando o SMB 3.x

Causa

Esse erro é registrado porque os Arquivos do Azure atualmente não oferecem suporte a multicanais SMB.

Solução

Este erro pode ser ignorado.

Não é possível acessar pastas ou arquivos cujo nome tem um espaço ou um ponto no final

Você não consegue acessar pastas ou arquivos do compartilhamento de arquivos do Azure durante a montagem no Linux, comandos como du e ls e/ou aplicativos de terceiros podem falhar com um erro "Arquivo ou diretório não existe" ao acessar o compartilhamento, no entanto, você pode carregar arquivos para as pastas citadas por meio do portal.

Causa

As pastas ou arquivos foram carregados de um sistema que codifica os caracteres no final do nome para um caractere diferente. Os arquivos carregados de um computador Macintosh podem ter um caractere "0xF028" ou "0xF029" em vez de 0x20 (espaço) ou 0X2E ( ponto).

Solução

Use a opção mapchars no compartilhamento ao montar o compartilhamento no Linux:

em vez de:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

use:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Problemas de DNS com a migração dinâmica de contas de armazenamento do Azure

A E/S de arquivo no sistema de arquivos montado começa a apresentar erros "O host está inoperante" ou "Permissão negada". Os logs de dmesg do Linux no cliente terão erros repetidos como:

Código de status retornado 0xc000006d STATUS_LOGON_FAILURE cifs_setup_session: 2 retornos de chamada suprimidos CIFS VFS: \contoso.file.core.windows.net Enviar erro em SessSetup = -13

Você também verá que o FQDN do servidor agora é resolvido para um endereço IP diferente daquele a que ele está conectado no momento.

Causa

Para fins de balanceamento de carga de capacidade, às vezes, as contas de armazenamento passam pela migração dinâmica de um cluster de armazenamento para outro. A migração de conta dispara o tráfego de Arquivos do Azure para ser redirecionado do cluster de origem para o cluster de destino, atualizando os mapeamentos de DNS para apontar para o cluster de destino. Isso faz com que todo o tráfego para o cluster de origem dessa conta seja bloqueado. Espera-se que o cliente SMB pegue as atualizações de DNS e redirecione o tráfego adicional para o cluster de destino. No entanto, devido a um bug no cliente do kernel SMB do Linux, esse redirecionamento não entrou em vigor. Como resultado, o tráfego de dados continuou indo para o cluster de origem, que havia parado de atender a essa conta após a migração.

Solução alternativa

Esse problema pode ser mitigado, basta reinicializar o sistema operacional cliente, mas você poderá encontrar o problema novamente se não atualizar o sistema operacional cliente para uma versão de distribuição do Linux com suporte para migração de conta. Observe que pode parecer que a desmontagem e a remontagem do compartilhamento corrigem o problema temporariamente.

Solução

Para uma correção permanente, atualize o sistema operacional cliente para uma versão de distribuição do Linux com suporte para migração de conta. Várias correções para o cliente do kernel SMB do Linux foram enviadas recentemente para o kernel do Linux de linha principal. O Kernel versão 5.15+ e o Keyutils-1.6.2+ receberam as correções. No entanto, a portabilidade retroativa dessas correções ainda não foi realizada para as distribuições populares do Linux nos kernels estáveis. Algumas distribuições realizaram a portabilidade retroativa dessas correções e você pode verificar se as seguintes correções existem na versão da distribuição que você está usando:

cifs: em cifs_reconnect, resolva o nome do host novamente

cifs: use a saída de expiração de dns_query para agendar a próxima resolução

cifs: definir no mínimo 120 s para a próxima resolução DNS

cifs: para corresponder aos servidores de arquivos, verifique se o nome do host do servidor corresponde

cifs: corrigir a perda de memória de smb3_fs_context_dup::server_hostname

dns: aplicar um TTL padrão aos registros obtidos de getaddrinfo()

Precisa de ajuda? Entre em contato com o suporte.

Caso ainda precise de ajuda, contate o suporte para resolver seu problema rapidamente.