Laboratório de Troubleshooting: Create and configure a file share in Azure Files
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador reporta que uma VM Windows Server 2022 hospedada no Azure não consegue montar um compartilhamento Azure Files usando o seguinte comando:
net use Z: \\storprod01.file.core.windows.net\dados /user:Azure\storprod01 <chave_de_acesso>
A saída retornada é:
System error 53 has occurred.
The network path was not found.
O administrador confirma que:
- O nome da conta de armazenamento e o nome do compartilhamento estão corretos
- A chave de acesso foi copiada diretamente do portal
- A VM tem acesso à internet e consegue resolver DNS público normalmente
- A conta de armazenamento foi criada há menos de 24 horas
- O compartilhamento tem quota configurada de 50 GiB
Um teste de conectividade foi executado na VM:
Test-NetConnection -ComputerName storprod01.file.core.windows.net -Port 445
ComputerName : storprod01.file.core.windows.net
RemoteAddress : 20.150.x.x
RemotePort : 445
TcpTestSucceeded : False
Qual é a causa raiz da falha de montagem?
A) A chave de acesso fornecida no comando está incorreta ou expirada.
B) A porta 445 está bloqueada na camada de rede entre a VM e o endpoint do Azure Files, impedindo a comunicação SMB.
C) O compartilhamento foi criado com quota insuficiente para o sistema operacional completar o processo de montagem.
D) O registro DNS da conta de armazenamento ainda não foi propagado completamente, pois a conta tem menos de 24 horas.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que um servidor de arquivos local sincronizado via Azure File Sync está apresentando lentidão ao abrir arquivos. Após investigação, a causa foi confirmada: o recurso de cloud tiering está reidratando arquivos com frequência elevada porque o volume local tem apenas 8% de espaço livre, abaixo do limiar de 20% configurado na política de espaço livre em volume.
O ambiente possui as seguintes restrições:
- O servidor está em produção com 200 usuários ativos
- Não é possível adicionar capacidade de disco nas próximas 6 horas
- O Azure File Sync está sincronizando normalmente sem erros de agente
- Existe um segundo servidor registrado no mesmo Sync Group, atualmente sem carga
- O time de storage pode executar ações no portal e via PowerShell
Qual é a ação correta a tomar neste momento?
A) Desabilitar o cloud tiering no endpoint do servidor afetado para forçar todos os arquivos a permanecerem localmente e eliminar a reidratação.
B) Remover o servidor afetado do Sync Group e adicionar o segundo servidor como endpoint ativo, redirecionando os usuários imediatamente.
C) Ajustar a política de cloud tiering para reduzir o limiar de espaço livre em volume para 5%, forçando o tiering de mais arquivos e liberando espaço local.
D) Transferir a carga de acesso para o segundo servidor registrado no Sync Group, que já possui os metadados sincronizados, enquanto o espaço do servidor primário é resolvido.
Cenário 3 — Causa Raiz
Um administrador configura autenticação baseada em identidade em um compartilhamento Azure Files para permitir que usuários do domínio acessem o conteúdo com permissões granulares. O ambiente usa Active Directory Domain Services local integrado via Microsoft Entra Connect.
Após a configuração, o administrador testa o acesso montando o compartilhamento na própria máquina de administração, que é um membro do domínio:
net use Z: \\storprodfs.file.core.windows.net\rh
O compartilhamento é montado com sucesso. No entanto, ao tentar acessar uma subpasta com permissões NTFS restritas a um grupo de segurança específico, o acesso é negado para todos os usuários testados, incluindo membros confirmados do grupo.
Informações coletadas:
| Item verificado | Status |
|---|---|
| Usuário é membro do grupo no AD local | Confirmado |
| Grupo sincronizado para Microsoft Entra ID | Confirmado |
| Permissão de compartilhamento (Share-level) | Contributor atribuído ao grupo |
| Permissões NTFS na subpasta | Grupo com Allow: Read, Write |
| Kerberos ticket obtido com sucesso | Confirmado |
| Versão do agente do Microsoft Entra Connect | 2.1.x (atualizada) |
Qual é a causa raiz do problema?
A) A permissão de nível de compartilhamento (Share-level) configurada como Contributor está em conflito com as permissões NTFS mais restritivas, e o Azure Files aplica a permissão mais restritiva entre as duas.
B) O Kerberos ticket obtido pelo cliente não inclui os grupos de segurança do AD local quando o acesso é feito via SMB ao Azure Files, pois o token é gerado com base no Microsoft Entra ID.
C) As permissões NTFS foram configuradas corretamente, mas o Azure Files exige que as ACLs sejam propagadas via icacls ou Windows Explorer a partir de uma máquina ingressada no domínio com uma sessão autenticada com a conta de domínio, e essa etapa não foi concluída.
D) A versão do Microsoft Entra Connect está desatualizada e não sincroniza corretamente as ACLs NTFS do AD local para o Azure Files.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta de um sistema de monitoramento:
Alert: Azure Files - Share Quota Exceeded
Storage Account: storbackup02
Share: backups-diarios
Configured Quota: 100 GiB
Current Usage: 100 GiB
New writes are being rejected.
O administrador nunca trabalhou nessa conta de armazenamento antes e precisa diagnosticar a situação antes de agir. Abaixo estão os passos de investigação disponíveis:
- Verificar se o soft delete está habilitado e se há snapshots ou versões retidas ocupando espaço não visível na listagem de arquivos ativos.
- Aumentar a quota do compartilhamento para 200 GiB para restaurar imediatamente a capacidade de escrita.
- Identificar quais arquivos ou diretórios consomem mais espaço dentro do compartilhamento usando métricas ou ferramentas de análise.
- Confirmar se a conta de armazenamento é GPv2 ou FileStorage e qual tier está configurado para entender os limites máximos aplicáveis.
- Verificar os logs de atividade da conta de armazenamento para identificar se houve crescimento anormal de dados nas últimas horas.
Qual é a sequência correta de diagnóstico antes de tomar qualquer ação corretiva?
A) 2 → 4 → 3 → 5 → 1
B) 4 → 5 → 3 → 1 → 2
C) 5 → 1 → 2 → 4 → 3
D) 3 → 1 → 4 → 5 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do comando Test-NetConnection: TcpTestSucceeded: False na porta 445. Isso confirma que a camada de transporte está bloqueada. O erro 53 no net use ("network path was not found") é o sintoma exato de falha de conectividade TCP antes mesmo de qualquer negociação SMB ocorrer.
A informação sobre a conta ter menos de 24 horas e a quota de 50 GiB são dados irrelevantes inseridos propositalmente. A propagação de DNS não causaria falha de TCP após resolução bem-sucedida de nome, e quota não tem relação alguma com a fase de montagem.
O distrator mais perigoso é a opção A, que leva o administrador a perder tempo trocando credenciais em vez de verificar conectividade de rede. Escolher A resultaria em múltiplas tentativas frustradas com chaves válidas, atrasando o diagnóstico real.
Gabarito — Cenário 2
Resposta: D
A causa já foi identificada no enunciado: espaço local insuficiente causando reidratação excessiva. A restrição crítica é que não é possível adicionar disco nas próximas 6 horas. A ação correta deve aliviar a carga imediatamente sem remover o servidor do ambiente de produção de forma abrupta.
O segundo servidor já está registrado no mesmo Sync Group, o que significa que ele possui os mesmos arquivos (ou reparse points) e pode assumir carga de leitura imediatamente, sem necessidade de ressincronização completa.
- A opção A é tecnicamente possível, mas desabilitar o cloud tiering sem espaço disponível forçaria a reidratação total de todos os arquivos em tier, o que pioraria o problema imediatamente.
- A opção C é contraditória: reduzir o limiar abaixo do nível atual (8%) não força mais tiering, pois o sistema já está operando além do limiar; apenas liberaria espaço se houvesse mais arquivos elegíveis para tier, mas não resolve a lentidão de reidratação.
- A opção B é uma ação irreversível e destrutiva para um ambiente com 200 usuários ativos sem janela de manutenção.
Gabarito — Cenário 3
Resposta: C
O cenário descreve uma configuração tecnicamente correta em todos os pontos verificados: grupo correto, permissões Share-level e NTFS atribuídas, Kerberos funcionando. O detalhe crítico está na forma como as ACLs NTFS foram configuradas.
No Azure Files com autenticação via AD DS, as permissões NTFS precisam ser gravadas diretamente nos metadados do compartilhamento por uma sessão autenticada com identidade de domínio. Configurar as ACLs via portal ou ferramentas que não usam a sessão autenticada Kerberos resulta em ACLs não aplicadas corretamente nos metadados do sistema de arquivos remoto. O passo de aplicar as ACLs via icacls ou Windows Explorer a partir de uma sessão de domínio é obrigatório e frequentemente omitido.
A opção A representa um equívoco comum: o Azure Files aplica a interseção das permissões Share-level e NTFS, portanto um Contributor com NTFS Read/Write resultaria em acesso, não em bloqueio.
A opção D é o distrator irrelevante do cenário: a versão do Microsoft Entra Connect nunca sincroniza ACLs NTFS para o Azure Files; esse não é o seu papel na integração com AD DS para Azure Files.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico segue a lógica de entender o ambiente antes de qualquer ação corretiva:
4 (entender o tipo de conta e limites) → 5 (verificar se o crescimento foi anormal ou esperado) → 3 (identificar o que está consumindo espaço) → 1 (verificar se soft delete/snapshots estão retendo espaço invisível) → 2 (só então ampliar a quota, se necessário).
O passo 2 é sempre o último porque aumentar a quota sem entender a causa pode mascarar um problema de crescimento descontrolado, como um job de backup com retenção mal configurada.
A sequência A começa com a ação corretiva (passo 2) antes de qualquer diagnóstico, o que é o erro mais comum sob pressão: resolver o sintoma imediato sem entender a causa, permitindo que o problema se repita em horas.
A sequência C coloca a análise de logs antes do entendimento da infraestrutura, gerando ruído interpretativo sem contexto.
Árvore de Troubleshooting: Create and configure a file share in Azure Files
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral e percorra as ramificações respondendo cada pergunta com base no que você observa no ambiente, não no que você supõe. Os nós em laranja indicam que uma verificação adicional é necessária antes de confirmar a causa. Nunca pule diretamente para um nó de ação sem ter passado pelo nó de causa correspondente: agir sem confirmar o diagnóstico é a origem da maioria dos incidentes prolongados em ambientes de storage.