Se a sua aplicação no Azure App Service for Linux utiliza Azure Files via NFS, é provável que você já tenha se deparado com erros de Permission denied ou Errno 13. Em ambientes Linux e Unix-like, o NFS trabalha com a lógica de ownership baseado em IDs numéricos (UID/GID), o que difere fundamentalmente do modelo de autenticação SMB.
Visão Geral
Este cenário é voltado para arquiteturas que utilizam o Azure App Service on Linux com Azure Files NFS para persistência de dados. É fundamental entender que o Azure Files NFS, projetado para workloads Linux e Unix, exige o cumprimento de permissões no padrão POSIX e não oferece suporte a clientes Windows ou ACLs de NFS tradicionais.
Um ponto crítico: falhas de escrita neste contexto raramente indicam corrupção de arquivos. O problema reside, quase sempre, na divergência entre o identity context do processo da aplicação e o proprietário esperado pelo mount point NFS. Em contêineres, o mapeamento de usuários (UIDs) dentro de um ambiente isolado pode diferir daquele visível no host, impactando diretamente o acesso a recursos montados.
Sinais Comuns
Você provavelmente está enfrentando esse problema se observar:
Permission deniedem logs de aplicação.Errno 13ao tentar realizar operações de E/S.- A aplicação consegue ler, mas falha ao atualizar ou sobrescrever arquivos.
- Ao inspecionar o mount path, o ownership do arquivo difere drasticamente do esperado.
Esses sintomas são reflexos diretos da forma como o modelo de permissões NFS é processado pelo sistema operacional, priorizando a identidade numérica sobre as credenciais de usuário gerenciadas via IAM.
Por que isso acontece?
O cerne da questão é a disparidade de identidades (UID/GID) entre contêiner e host. Conforme as especificações de user namespace do Docker, um usuário root dentro de um contêiner pode ser mapeado para um usuário não privilegiado no host. Como o NFS depende estritamente desses números para validar permissões, um arquivo criado por uma identidade no passado pode se tornar inacessível para escrita se a aplicação for redeployada com outro contexto de execução.
O que checar primeiro
Não assuma que os arquivos foram corrompidos. O primeiro passo para o troubleshooting deve ser a verificação do mount point a partir do contexto de runtime da sua aplicação:
ls -l /caminho/do/mount/arquivo
ls -ln /caminho/do/mount/arquivo
id -u
id -g
O comando ls -ln é o mais relevante, pois expõe o UID e GID reais. Se precisar investigar mais a fundo, o App Service permite SSH nos contêineres, embora custom containers possam exigir configurações adicionais para isso. Além disso, audite o squash setting do seu share NFS (No Root Squash, Root Squash ou All Squash), conforme as diretrizes de governança de segurança do seu ambiente.
Uma mitigação prática
Se a raiz do problema for a inconsistência no ownership, uma abordagem eficaz que costumamos recomendar é a utilização de All Squash no share NFS. Essa configuração centraliza o controle de identidade nas interações com o share. Lembre-se: alterar o squash setting não reescreve metadados de arquivos existentes. Se o volume estiver carregado com dados antigos, a reconfiguração pode exigir uma migração dos dados.
Abordagem recomendada
Para minimizar o downtime e garantir a integridade:
- Provisione um novo Azure Files NFS share.
- Aplique a configuração All Squash, se ela atender aos requisitos do seu workload.
- Monte o share antigo e o novo em um ambiente Linux de teste.
- Realize a cópia dos dados do antigo para o novo.
- Valide se a aplicação consegue realizar operações de leitura e escrita via novo volume.
- Realize o repoint do tráfego de produção para o volume validado.
Conclusão
Erros de Permission denied no Azure App Service com NFS geralmente são resolvidos validando o modelo de ownership e ajustando o squash setting. Antes de considerar uma restauração de backup ou diagnósticos complexos, foque nos mapeamentos de UID/GID do seu contêiner. Se a complexidade operacional exigir, migrar para uma nova estrutura de storage com as configurações corretas é o caminho mais seguro para restaurar a estabilidade da sua operação.
Referências
- NFS file shares in Azure Files | Microsoft Learn
- Configure Root Squash Settings for NFS Azure File Shares | Microsoft Learn
- SSH Access for Linux and Windows Containers - Azure App Service | Microsoft Learn
- Isolate containers with a user namespace | Docker Docs
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
