Montar compartilhamentos NFS de forma robusta: hard versus soft, timeo e o que acontece quando o servidor desaparece

Objetivo

Montar uma exportação NFS de modo que ela sobreviva a um servidor sem resposta e a uma reinicialização normal, e saber qual pacote e qual versão usar no RHEL e no Debian/Ubuntu.

Pré-requisitos

• Root para montar. Pacotes de cliente: nfs-utils no RHEL/Fedora, nfs-common no Debian/Ubuntu.
• O caminho da exportação e o endereço do servidor; showmount -e <server> lista as exportações do servidor (exige que mountd/rpcbind estejam acessíveis, o que importa principalmente para NFSv3).

Passos

1. Verifique o que o servidor oferece: showmount -e nfsserver. O showmount depende de mountd/rpcbind e pode não mostrar nada em um servidor apenas NFSv4, mesmo que as montagens funcionem. O NFSv4 apresenta as exportações em um único pseudo-sistema de arquivos e não precisa de rpcbind; o NFSv3 precisa de rpcbind, e o cliente só recorre a ele se o servidor não oferecer NFSv4 ou se vers=3 estiver definido.
2. Monte uma vez manualmente para testar: mount -t nfs -o vers=4.2 nfsserver:/export /mnt/data (sem vers=/nfsvers=, o mount -t nfs negocia a maior versão suportada pelos dois lados; vers=4.2 falha se o servidor não oferecer a 4.2).
3. Escolha de forma deliberada o comportamento em caso de falha no /etc/fstab:
   • hard (o padrão): a E/S na montagem bloqueia e é repetida indefinidamente se o servidor deixar de responder; um processo preso em uma chamada NFS nesse estado geralmente só termina com SIGKILL (a opção legada intr é ignorada desde o kernel 2.6.25). Isso protege contra perda silenciosa de dados em uma indisponibilidade passageira.
   • soft: a E/S desiste após retrans= retransmissões (cada uma aguardando timeo= décimos de segundo, com backoff linear sobre TCP) e devolve um erro à aplicação. Só é apropriado quando a aplicação já trata corretamente erros de E/S, pois soft pode corromper silenciosamente um estado que pressupunha que as gravações tinham sido bem-sucedidas.
   • Sobre TCP, os padrões já são timeo=600 (60 segundos) e retrans=2; aumente retrans= para ampliar a janela antes de uma montagem soft desistir em links instáveis.
4. Ordem em relação à rede: o systemd já reconhece nfs/nfs4 como sistemas de arquivos de rede e os ordena depois da rede; _netdev só é necessário quando essa detecção falha (por exemplo, em sistemas de arquivos sobre iSCSI) e é inofensivo em uma linha NFS.
5. Para evitar que o boot trave quando o servidor NFS está fora do ar, adicione x-systemd.automount,x-systemd.mount-timeout=30 às opções da entrada: a montagem só é disparada no primeiro acesso, com um timeout limitado, em vez de bloquear a sequência de boot (nofail sozinho também faz o boot deixar de esperar por ela). Depois de editar o fstab, execute systemctl daemon-reload.
6. Monte tudo o que está no fstab e verifique: mount -a, depois mount | grep nfs e nfsstat --client para as estatísticas de RPC do lado do cliente (retransmissões aqui indicam um caminho instável mesmo quando a montagem parece estar ativa).

Resultado esperado

O compartilhamento fica acessível, o mount -a termina sem travar, e um servidor NFS parado de propósito produz o comportamento escolhido (repetição indefinida com hard, um erro em tempo limitado com soft) em vez de um travamento de boot não planejado.

Limites e base de verificação

Opções verificadas em nfs(5), mount.nfs(8) e systemd.mount(5) (_netdev, x-systemd.automount). Para desfazer: comente ou remova a linha do fstab e execute umount /mnt/data; desmontar não afeta nenhum dado no cliente.