Solucionar problemas de compartilhamentos de arquivos do NFS do Azure

Este artigo lista alguns problemas comuns relativos aos compartilhamentos de arquivos do NFS do Azure e apresenta possíveis causas e soluções alternativas.

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

Falha do "nome do arquivo" do chgrp: argumento inválido (22)

Causa 1: o idmapping não está desabilitado

Devido ao fato de o Arquivos do Azure não permitir UID/GID alfanuméricos, você precisa desabilitar o idmapping.

Causa 2: o idmapping foi desabilitado, mas foi reabilitado após encontrar um nome de arquivo/dir inadequado

Mesmo se você desabilitá-lo corretamente, o idmapping poderá ser habilitado novamente automaticamente em alguns casos. Por exemplo, o Arquivos do Azure retorna um erro quando encontra um nome de arquivo inadequado. Após ver esse código de erro específico, um cliente do NFS 4.1 Linux decide habilitar o idmapping novamente e passa a enviar as solicitações futuras com UID/GID alfanuméricos. Para obter uma lista de caracteres sem suporte nos Arquivos do Azure, confira este artigo. Dois-pontos é um dos caracteres sem suporte.

Solução alternativa

Certifique-se de ter desabilitado o idmapping e de que nenhum recurso irá habilitá-lo novamente. Em seguida, siga estas etapas:

1. Desmontar o compartilhamento.

2. Desative o idmapping com:

   sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

3. Monte a parte de volta.

4. Se estiver executando rsync, execute rsync com o —numeric-ids argumento de um diretório que não tenha um diretório ou nome de arquivo inválido.

Não é possível criar um compartilhamento NFS

Causa: configurações de conta de armazenamento sem suporte

O NFS só está disponível em contas de armazenamento com a seguinte configuração:

• Camada – Premium
• Tipo de conta – FileStorage
• Regiões – Lista de regiões com suporte

Solução

Siga as instruções em Como criar um compartilhamento do NFS.

Não foi possível se conectar ao serviço ou montar um compartilhamento de arquivos do NFS do Azure

Causa 1: a solicitação provém de um cliente em uma rede não confiável/IP não confiável

Diferentemente do SMB, o NFS não tem uma autenticação baseada no usuário. A autenticação de um compartilhamento se baseia na configuração de sua regra de segurança de rede. Para se certificar de que os clientes estabeleçam apenas conexões seguras com seu compartilhamento do NFS, você precisa usar um ponto de extremidade de serviço ou pontos de extremidade privados. Para acessar compartilhamentos a partir do local, além dos pontos de extremidade privados, você precisa configurar a VPN ou uma conexão ExpressRoute. Os IPs adicionados à lista de permitidos da conta de armazenamento para o firewall são ignorados. Você precisa usar um dos seguintes métodos para configurar o acesso a um compartilhamento NFS:

• Ponto de extremidade de serviço

  • Acessado pelo ponto de extremidade público.

  • Disponível somente na mesma região.

  • Você não pode usar o emparelhamento de VNet para acessar o compartilhamento.

  • Você precisa adicionar cada rede ou sub-rede virtuais à lista de permissões individualmente.

  • No caso do acesso local, você pode usar pontos de extremidade de serviço com o ExpressRoute e VPNs de conexão ponto a site e site a site. Recomendamos o uso de um ponto de extremidade privado porque é mais seguro.

    O diagrama a seguir ilustra a conectividade usando pontos de extremidade públicos:

    

• Ponto de extremidade privado

  • O acesso é mais seguro do que o ponto de extremidade de serviço.

  • O acesso ao compartilhamento do NFS por meio de um link privado está disponível a partir de dentro e de fora da região do Azure da conta de armazenamento (entre regiões, no local).

  • O emparelhamento de rede virtual com redes virtuais hospedadas no ponto de extremidade privado concede aos clientes acesso ao compartilhamento do NFS em redes virtuais emparelhadas.

  • Você pode usar pontos de extremidade privados com o ExpressRoute e VPNs de conexão ponto a site e site a site.

    

Causa 2: a transferência segura necessária está habilitada

Atualmente, os compartilhamentos de arquivos do NFS do Azure não são compatíveis com criptografia dupla. O Azure fornece uma camada de criptografia para todos os dados em trânsito entre datacenters do Azure usando o MACsec. Você só pode acessar compartilhamentos do NFS a partir de redes virtuais confiáveis e por meio de túneis de VPN. Nenhuma criptografia adicional da camada de transporte está disponível nos compartilhamentos do NFS.

Solução

Desabilite a transferência segura necessária na folha de configuração da conta de armazenamento.

Causa 3: o pacote nfs-utils, nfs-client ou nfs-common não está instalado

Antes de executar o mount comando, instale o pacote nfs-utils, nfs-client ou nfs-common.

Para verificar se o pacote NFS está instalado, execute:

sudo rpm -qa | grep nfs-utils

sudo rpm -qa | grep nfs-client

sudo dpkg -l | grep nfs-common

Solução

Se o pacote não estiver instalado, instale-o usando o comando específico para a sua distribuição (distro-specific).

sudo yum install nfs-utils

sudo dnf install nfs-utils

sudo zypper install nfs-client

sudo apt update
sudo apt install nfs-common

Causa 4: firewall bloqueando a porta 2049

O protocolo NFS se comunica com seu servidor por meio da porta 2049. Certifique-se de que essa porta esteja aberta para a conta de armazenamento (o servidor NFS).

Solução

Verifique se a porta 2049 está aberta no cliente executando o comando a seguir. Se a porta não estiver aberta, abra-a.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Causa 5: conta de armazenamento excluída

Se você não conseguir montar o compartilhamento de arquivos devido ao erro: a conexão expirou, a conta de armazenamento que contém o compartilhamento de arquivos poderá ser excluída acidentalmente.

Solução

Recupere a conta de armazenamento. Em seguida, exclua e recrie o ponto de extremidade privado para que ele seja associado à nova ID de recurso da conta de armazenamento.

ls trava para enumeração de diretório grande em alguns kernels

Causa: Um bug foi introduzido no kernel Linux v5.11 e foi corrigido na v5.12.5

Algumas versões do kernel têm um bug que faz com que as listagem de diretório resultem em uma sequência READDIR infinita. Diretórios muito pequenos em que todas as entradas podem ser enviadas em uma única chamada não terão esse problema. O bug foi introduzido no Kernel Linux v5.11 e foi corrigido na v5.12.5. Portanto, os bugs estão presentes em todas as versões intermediárias. O RHEL 8.4 tem essa versão de kernel.

Solução alternativa: fazer o downgrade ou upgrade do kernel

Fazer o downgrade ou upgrade do kernel para qualquer versão que não seja a do kernel afetado deve resolver o problema.

Os comandos do sistema falham com o erro "Arquivo não encontrado"

Motivo

Os aplicativos Linux de 32 bits que dependem de números de inode podem não funcionar conforme o esperado com os Arquivos do Azure devido à formatação dos números de inode de 64 bits gerados pelo serviço NFS.

Solução

Para resolver esse problema, use um dos seguintes métodos:

• Comprima os números de inode de 64 bits para 32 bits usando a opção de inicialização do nfs.enable_ino64=0 kernel.

• Defina o parâmetro do módulo adicionando options nfs enable_ino64=0 ao arquivo /etc/modprobe.d/nfs.conf e reinicializando a VM.

Você também pode persistir essa opção de inicialização do kernel no arquivo grub.conf . Para obter mais informações, consulte a documentação da sua distribuição do Linux.

Não é possível alterar a propriedade de arquivos e diretórios

Motivo

As permissões em compartilhamentos de arquivos NFS são impostas pelo sistema operacional cliente em vez do serviço de Arquivos do Azure. Se a configuração Root Squash estiver habilitada em um compartilhamento de arquivos NFS, o usuário raiz no sistema cliente será tratado como um usuário anônimo (não privilegiado) para fins de controle de acesso. Isso significa que, mesmo que você esteja conectado como root no sistema do cliente, não poderá usar o chown comando para alterar a propriedade de arquivos e diretórios que não são seus.

Solução

No portal do Azure, navegue até o compartilhamento de arquivos e selecione Propriedades. Altere a configuração Root Squash para No Root Squash. Para obter mais informações, consulte Configurar squash raiz para Arquivos do Azure.

Sem Root Squash habilitado, o usuário raiz no sistema cliente tem os mesmos privilégios que o usuário raiz no sistema do servidor. Agora você pode usar chown para alterar a propriedade de qualquer arquivo ou diretório no compartilhamento, independentemente do proprietário atual. Depois de fazer as alterações, você pode reativar o Root Squash , se necessá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 do Arquivos do Azure (SMB)
• Solução de problemas gerais do SMB nos Arquivos do Azure no Linux

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.