Solucionar problemas de Arquivos do Azure no Linux (SMB)

  • Artigo

Este artigo lista problemas comuns que podem ocorrer ao usar compartilhamentos de arquivos do Azure SMB com clientes Linux. Ele também fornece possíveis causas e resoluções para esses problemas.

Você pode usar o AzFileDiagnostics para automatizar a detecção de sintomas e garantir que o cliente Linux tenha os pré-requisitos corretos. Ele ajuda a configurar seu ambiente para obter o desempenho ideal. Você também pode encontrar essas informações no solucionador de problemas de compartilhamentos de arquivos do Azure.

Importante

Este artigo só se aplica a compartilhamentos SMB. Para obter detalhes sobre compartilhamentos NFS, consulte Solucionar problemas de compartilhamentos de arquivos do Azure da NFS.

Aplicável a

Tipo de compartilhamento de arquivo SMB NFS
Compartilhamentos de arquivo padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivo padrão (GPv2), GRS/GZRS
Compartilhamentos de arquivo Premium (FileStorage), LRS/ZRS

Os carimbos de tempo foram perdidos ao copiar arquivos

Nas plataformas Linux/Unix, o cp -p comando falhará se diferentes usuários tiverem o arquivo 1 e o arquivo 2.

Motivo

O sinalizador de f força no COPYFILE resulta na execução cp -p -f no Unix. Esse comando também falha ao preservar o carimbo de 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 '<path>': 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ê obtém o seguinte erro:

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

Solução

Atualize o kernel do Linux para as seguintes versões que têm uma correção para este problema:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Todas as versões maiores ou iguais a 4.13

Não é possível criar links simbólicos – ln: falha ao criar o link simbólico 't': Operação sem suporte

Motivo

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 (symlinks). Você pode 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 Windows no protocolo SMB 2 ou 3. Atualmente, o cliente Linux dá suporte a outro estilo de links simbólicos chamados symlinks Minshall+French para operações de criação e acompanhamento. 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 symlinks, adicione o seguinte ao fim do comando de montagem do 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 symlinks conforme sugerido no wiki.

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

Você não pode acessar pastas ou arquivos do compartilhamento de arquivos do Azure enquanto estiver montado no Linux. Comandos como du e ls e/ou aplicativos de terceiros podem falhar com um erro "Nenhum arquivo ou diretório" ao acessar o compartilhamento; no entanto, você pode carregar arquivos nessas pastas por meio do portal do Azure.

Motivo

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 do arquivo no sistema de arquivos montado começa a dar erros de "Host está desativado" ou "Permissão negada". Os logs de 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 do que ele está conectado no momento.

Motivo

Para fins de balanceamento de carga de capacidade, as contas de armazenamento às vezes são migradas ao vivo de um cluster de armazenamento para outro. A migração da conta dispara Arquivos do Azure tráfego a ser redirecionado do cluster de origem para o cluster de destino atualizando os mapeamentos 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 pegue as atualizações 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 entra em vigor. 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á executar o problema novamente se não atualizar o sistema operacional cliente para uma versão de distro do Linux com suporte para migração de conta. Observe que a desmontagem e a remontagem do compartilhamento podem aparecer para corrigir o problema temporariamente.

Para solucionar melhor esse problema, desmarque o cache de resolver 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 de comando como o seguinte exemplo:

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

  2. Desmarque o cache de resolver DNS do kernel executando o seguinte comando:

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

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

    grep '.dns_resolver' /proc/keys

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

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

Solução

Para uma correção permanente, atualize o sistema operacional cliente para uma versão de distro 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 linux de linha principal. O Kernel versão 5.15+ e o Keyutils-1.6.2+ têm as correções. Algumas distros têm backported essas correções e você pode marcar se as seguintes correções existirem na versão de distro que você está usando:

Não é possível montar o compartilhamento de arquivos SMB quando o FIPS estiver 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 de 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 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.

Motivo

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. O 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 marcar se o modo FIPS estiver habilitado

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

sudo cat /proc/sys/crypto/fips_enabled

Solução

Para resolve esse problema, habilite a autenticação Kerberos para compartilhamento de arquivos SMB. Se o FIPS estiver habilitado involuntariamente, consulte a opção2 para desabilitar.

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

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

Opção 2: Desabilitar o FIPS para montar o compartilhamento de Samba

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

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

  3. Reconstruiu o arquivo de configuração grub2 com o seguinte comando:

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

  4. Recompilar a imagem initramfs com o seguinte comando:

    sudo dracut -fv

  5. Reinicialize a VM.

Para obter mais informações, confira os seguintes documentos de distribuidores linux:

Precisa de ajuda?

Se você ainda precisar de ajuda, entre em contato com o suporte para resolver o 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.