Solução de problemas dos Arquivos do Azure no Linux (SMB)

  • Artigo

Este artigo lista os problemas comuns que podem ocorrer quando os compartilhamentos de arquivos SMB do Azure são usados com os clientes Linux. Também fornece as possíveis causas e resoluções para esses problemas.

Você pode usar AzFileDiagnostics para automatizar a detecção de sintomas e garantir que o cliente Linux tenha os pré-requisitos corretos. 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.

Importante

Este artigo só se aplica aos 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
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS

Os carimbos de data/hora foram perdidos ao copiar arquivos

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

Causa

O sinalizador f force em COPYFILE resulta na execução 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 ls comando, 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: falha ao criar link simbólico 't': Operação sem suporte

Causa

Por padrão, a montagem de compartilhamentos de arquivos do Azure no Linux usando o SMB não habilita o suporte para links simbólicos. Você poderá ver um erro como este:

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Solução

O cliente SMB do Linux não dá suporte à 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 comando de montagem SMB:

,mfsymlinks

Portanto, o comando se parece com o seguinte:

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.

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

Não é possível acessar pastas ou arquivos no compartilhamento de arquivo do Azure enquanto ele está montado no Linux. Comandos como du e ls e/ou aplicativos de terceiros poderão falhar com o erro "O arquivo ou o diretório não existe" ao acessar o compartilhamento. No entanto, você pode carregar arquivos nessas pastas por meio do portal do Azure.

Causa

As pastas ou os 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 do dmesg do Linux no cliente mostram erros repetidos como:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

Você também verá que o FQDN do servidor agora é resolvido para um endereço IP diferente daquele ao qual está conectado no momento. Esse problema pode ocorrer em qualquer cenário em que o endereço IP do servidor possa ser alterado, como migração de conta. Outro cenário conhecido é o failover da conta de armazenamento porque o mapeamento DNS pode ser alterado.

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 bloqueia todo o tráfego para o cluster de origem dessa conta. Espera-se que o cliente SMB selecione 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 tem nenhum efeito. Como resultado, o tráfego de dados continua indo para o cluster de origem, que parou de atender a essa conta após a migração.

Solução alternativa

Você pode atenuar esse problema reinicializando o sistema operacional cliente, mas 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.

Embora desmontar e remontar o compartilhamento possa parecer resolver o problema temporariamente, não é uma solução permanente. Quando o cliente se reconecta ao servidor, o problema pode ocorrer novamente. A mitigação temporária ocorre porque uma nova ação de montagem ignora o cache do kernel SMB e resolve o endereço DNS no espaço do usuário. No entanto, o cache DNS do kernel é utilizado durante qualquer recuperação de desconexão de rede, o que pode fazer com que o problema ocorra novamente. Esse comportamento persiste mesmo fora das migrações de conta de armazenamento.

Para contornar melhor esse problema, limpe o cache do resolvedor de DNS do kernel:

  1. Exiba o status do módulo do kernel dns_resolver executando o seguinte comando:

    grep '.dns_resolver' /proc/keys

    Você deve ver a saída do comando como no exemplo a seguir:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. Limpe o cache do resolvedor de DNS do kernel executando o seguinte comando:

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. Exibe o status do módulo do kernel dns_resolver novamente:

    grep '.dns_resolver' /proc/keys

    Você deve ver a saída do comando como no exemplo a seguir, indicando que o cache agora está vazio:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. Desmonte e remonte o compartilhamento para atenuar o problema.

Observação

Em algumas distribuições Linux mais antigas, as etapas de mitigação anteriores podem não funcionar. Nesses casos, a reinicialização do sistema operacional cliente é a única mitigação conhecida.

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 para o kernel do Linux de linha principal. As seguintes distribuições têm as correções:

  • Ubuntu: 20.04, 22.04, 24.04 e AKS 22.04 (as correções são implementadas na versão 5.15.0-1068 do kernel)
  • RHEL: 8.6+
  • SLES: 15SP2, 15SP3, 15SP4 e 15SP5
  • Linux do Azure: 2.0 (as correções são distribuídas na versão 5.15.159.1 do kernel) e 3.0

Algumas distribuições fizeram backport dessas correções. Você pode verificar se as seguintes correções existem na versão da distro que está usando:

Não é possível montar o compartilhamento de arquivos SMB quando o FIPS está habilitado

Quando o FIPS (Federal Information Processing Standard) está habilitado em uma VM do Linux, o compartilhamento de arquivos SMB não pode ser montado. Os logs dmesg do Linux no cliente exibem erros como:

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Importante

O FIPS é um conjunto de padrões que o governo dos EUA usa para garantir a segurança e a integridade dos sistemas de computador. Quando um sistema está no modo FIPS, ele adere a requisitos criptográficos específicos descritos por esses padrões.

Causa

O cliente do compartilhamento de arquivos SMB usa a autenticação NTLMSSP, que requer o algoritmo de hash MD5. No entanto, no modo FIPS, o algoritmo MD5 é restrito porque não é compatível com FIPS. MD5 é uma função de hash amplamente usada que produz um valor de hash de 128 bits. No entanto, o MD5 é considerado inseguro para fins criptográficos.

Como verificar se o modo FIPS está ativado

Para verificar se o modo FIPS está habilitado no cliente, execute o comando a seguir. Se o valor for definido como 1, o FIPS será ativado.

sudo cat /proc/sys/crypto/fips_enabled

Solução

Para resolver esse problema, habilite a autenticação Kerberos para compartilhamento de arquivos SMB. Se o FIPS for ativado involuntariamente, consulte a opção 2 para desativá-lo.

Opção 1: habilitar a autenticação Kerberos para compartilhamento de arquivos SMB

Para montar um compartilhamento de arquivos SMB na VM do Linux em que o FIPS está habilitado, use a autenticação Kerberos/Azure AD. Para obter mais informações, confira Habilitar autenticação do Active Directory por SMB para clientes Linux acessando os Arquivos do Azure.

Opção 2: Desativar o FIPS para montar o compartilhamento do Samba

  1. Altere o valor sysctl de crypto.fips_enabled para 0 em /etc/sysctl.conf.

  2. Modifique o GRUB_CMDLINE_LINUX_DEFAULT arquivo in /etc/default/grub e remova o parâmetro fips=1.

  3. Reconstruído o arquivo de configuração do grub2 com o seguinte comando:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. Reconstrua a imagem initramfs com o seguinte comando:

    sudo dracut -fv

  5. Reinicialize a VM.

Para obter mais informações, consulte os seguintes documentos de distribuidores Linux:

Precisa de ajuda?

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

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.