Solução de problemas dos Arquivos do Azure no Linux (SMB)
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.
Motivo
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.
Motivo
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:
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
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\ ) ))
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
Desmonte e remonte o compartilhamento para atenuar o problema.
Observação
Em algumas distribuições Linux mais antigas, as etapas de mitigação podem não funcionar. Nesses casos, a reinicialização do sistema operacional cliente resolverá o problema temporariamente. Para uma correção permanente, você pode adicionar um ponto de extremidade privado à sua conta de armazenamento e conectar-se ao compartilhamento de arquivos usando um link privado.
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:
cifs: use a saída de expiração de dns_query para agendar a próxima resolução
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()
chaves: Correção da substituição da expiração da chave na instanciação
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.
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. 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
Altere o valor sysctl de
crypto.fips_enabled
para 0 em/etc/sysctl.conf
.Modifique o
GRUB_CMDLINE_LINUX_DEFAULT
arquivo in/etc/default/grub
e remova o parâmetrofips=1
.Reconstruído o arquivo de configuração do grub2 com o seguinte comando:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Reconstrua a imagem initramfs com o seguinte comando:
sudo dracut -fv
Reinicialize a VM.
Para obter mais informações, consulte os seguintes documentos de distribuidores Linux:
- RedHat: Por que habilitar o modo FIPS no kernel quebraria as montagens CIFS
- SUSE: A montagem CIFS falha com o erro "erro de montagem (2): Não existe esse arquivo ou diretório"
Precisa de ajuda?
Caso ainda precise de ajuda, contate o suporte para resolver seu problema rapidamente.
Confira também
- Solucionar problemas dos Arquivos do Azure
- Solucionar problemas de desempenho dos Arquivos do Azure
- Solução de problemas de conectividade dos Arquivos do Azure (SMB)
- Solução de problemas de autenticação e autorização dos Arquivos do Azure (SMB)
- Solução de problemas gerais do NFS nos Arquivos do Azure no Linux
- Solução de problemas da Sincronização de Arquivos do Azure
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.