APRENDER. PRATICAR. EVOLUIR.Confirmar o destino antes de entregar
O laboratório começa com uma pasta local que contém LOCAL-ONLY.txt. A consulta findmnt para esse caminho mostra tmpfs. Depois da montagem, a mesma consulta mostra nfs4, origem 127.0.0.1:/ e versão 4.2. O ficheiro local deixa de aparecer, sem ter sido copiado para o export. Esta sequência dá ao aluno uma observação concreta para investigar jobs que ficam verdes enquanto o consumidor não recebe nada. Num caso fictício, contém novas execuções e conserva o inventário antes de montar por cima de uma pasta já usada. A aceitação precisa de confirmar o filesystem do processo relevante, porque um caminho familiar ou uma entrada de configuração não demonstra onde os bytes foram escritos.
Interpretar o mapeamento de root
O export inicial permite escrita, usa root_squash e define explicitamente o UID e GID anónimos como 65534. Um pedido feito por UID 0 cria um ficheiro com esses valores no servidor. Ao tentar escrever numa pasta privada root:root em modo 0700, o mesmo cliente recebe EACCES. A recusa não demonstra indisponibilidade do NAS: identifica uma operação que a identidade mapeada não pode executar. A oficina pede uma explicação curta para o ticket e uma proposta de investigação com a conta real do batch. Repetir sudo no cliente não muda o mapeamento observado. Remover o controlo antes de reproduzir a identidade correta pode ampliar privilégios sem resolver o requisito funcional pretendido.
Comparar identidades normais e política efetiva
O pedido do UID 20001 cria um ficheiro cujo ownership mantém 20001. Numa pasta 0700 desse proprietário, a escrita passa para 20001 e falha para 20002. Não foram criadas contas de domínio: o guião usa identificadores numéricos sintéticos num único Linux. A fase seguinte desmonta o cliente, publica um export de leitura e volta a montar; uma criação recebe EROFS. Por fim, all_squash com anonuid 25000 faz um pedido de 20001 criar com UID 25000. Compara os três resultados numa tabela. O exercício distingue identidade preservada, identidade mapeada e escrita recusada pelo export. Cada alteração é delimitada ao ambiente descartável e fica acompanhada pela tabela efetiva de exports.
Passar do resultado local à aceitação empresarial
Depois da desmontagem, LOCAL-ONLY.txt reaparece e o ficheiro remoto continua no servidor. O guião remove o export, termina os seus serviços e verifica ausência da montagem cliente e de threads nfsd. As duas execuções guardam resultados, versões e hash do guião; o processo da VM foi confirmado como terminado após poweroff. Esta evidência tem limites: cliente e servidor partilham um kernel, sec=sys usa identidades numéricas e não houve Kerberos, TLS, ACLs empresariais ou clientes independentes. Num projeto fictício, transforma a tabela do laboratório em critérios para a plataforma real, com identidades aprovadas e operações permitidas e recusadas. O ensaio local prepara essa decisão, mas não constitui a aprovação da arquitetura empresarial.
# Guarded execution INSIDE the prepared disposable RAM-root VM.
# Preparation and limits: content/labs/nas-nfs/README.txt
python3 /mnt/dr/run.py --output /mnt/dr/evidence.json
# Actual recorded scope: Linux NFSv4.2, sec=sys, guest loopback.
# No enterprise data, Kerberos, TLS or injected fault.Um ficheiro criado por root através do export fica com UID 65534; outro criado pelo UID 20001 mantém esse identificador sob root_squash.
Armadilhas comuns
Tratar a existência da pasta como montagem, conceder no_root_squash antes de reproduzir a conta correta ou usar nomes como prova de identidade numérica.
Tópicos relacionados: Permissões Samba e identidade · Reconstrução de hosts e migração
O diagnóstico deve ligar caminho, montagem, identidade e operação. Um export gravável continua sujeito a permissões e mapeamento.
Referência: Linux NFS export policy and identity mapping · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior