Dia 18: NFS e Samba — Partilha de Ficheiros Linux e Windows

O NFS (Network File System) é o protocolo nativo de partilha de ficheiros entre sistemas Linux/Unix, enquanto o Samba (SMB/CIFS) permite que máquinas Windows acedam a directórios num servidor Linux e vice-versa. Um sysadmin precisa de dominar ambos: NFS para cenários de alto desempenho em ambientes homogéneos Linux (clusters, storage de VMs, home directories centralizados) e Samba para integração em redes mistas onde existem estações Windows. A configuração incorrecta de qualquer um deles pode expor dados sensíveis a toda a rede ou provocar problemas de permissões difíceis de diagnosticar.

⚠ Atenção: Nunca exponhas partilhas NFS ou Samba diretamente à Internet. Ambos os protocolos assumem uma rede interna de confiança. Usa sempre uma VPN ou firewall para isolar o tráfego de partilha de ficheiros.

Este artigo cobre a instalação e configuração de um servidor NFSv4, de um servidor Samba standalone (sem AD), o montar de partilhas em clientes Linux, o acesso a partir de Windows, e os erros mais comuns que surgem em ambientes reais.

1. O que são NFS e Samba — Protocolos e Casos de Uso

O NFS (Network File System) foi originalmente desenvolvido pela Sun Microsystems em 1989 e é hoje o standard de facto para partilha de ficheiros em ambientes Unix/Linux. A versão actual é a NFSv4 (RFC 7530), que trouxe melhorias significativas face ao NFSv3: funciona sobre uma única porta (2049/TCP) em vez de múltiplas portas RPC, inclui suporte nativo a ACLs, stateful sessions, e integração com Kerberos para autenticação forte. O NFS assume que o servidor e os clientes partilham um modelo de confiança baseado em endereços IP e UIDs — não há autenticação de utilizador por password no protocolo base (a menos que se use Kerberos).

O Samba implementa o protocolo SMB (Server Message Block) / CIFS, originalmente criado pela IBM e posteriormente estendido pela Microsoft. O Samba permite que um servidor Linux atue como file server e print server para clientes Windows, integrar uma máquina Linux num domínio Active Directory, ou atuar como controlador de domínio. A versão actual (Samba 4.x) suporta SMB2/SMB3, que traz encriptação de tráfego, múltiplas sessões por conexão, e melhor desempenho. O Samba pode funcionar em modo standalone (sem domínio, autenticação por utilizador local) ou integrado num domínio AD.

A regra prática para escolher entre os dois é simples: se todos os clientes são Linux/Unix, usa NFS (mais rápido, menos overhead, configuração mais limpa). Se há clientes Windows na mistura, usa Samba. Em ambientes mistos é comum ter ambos a correr no mesmo servidor, servindo diferentes directórios.

Característica NFS Samba (SMB/CIFS)
Clientes nativos Linux/Unix Windows, Linux, macOS
Porta principal 2049 TCP/UDP 445 TCP (SMB2/3)
Autenticação IP/UID (ou Kerberos) Utilizador/password (NTLM/Kerberos)
Permisões UID/GID Unix, ACLs NFSv4 ACLs Windows, herança
Desempenho (Linux-Linux) Excelente Bom (SMB3 com multichannel)
Caso de uso típico Home dirs, storage VM, clusters File server para Windows, redes mistas

2. NFS — Instalação do Servidor

O pacote do servidor NFS chama-se nfs-kernel-server no Debian/Ubuntu e nfs-utils no RHEL/Rocky/Alma. O kernel Linux inclui o módulo NFS nativamente, pelo que o servidor é o userspace daemon que gere os pedidos RPC. Instala o pacote apropriado:

# Debian/Ubuntu
sudo apt update
sudo apt install nfs-kernel-server nfs-common

# RHEL/Rocky/Alma/Fedora
sudo dnf install nfs-utils

Após a instalação, verifica se o serviço está activo. No Debian/Ubuntu e no RHEL o serviço principal chama-se nfs-server (via systemd). Inicia e activa ao arranque:

sudo systemctl enable --now nfs-server
sudo systemctl status nfs-server

O rpcbind é um serviço auxiliar que mapeia programas RPC para portas de rede. No NFSv4 puro, o rpcbind é tecnicamente opcional (NFSv4 usa a porta 2049 directamente), mas muitas ferramentas de gestão ainda dependem dele. Mantém-no activo para compatibilidade:

sudo systemctl enable --now rpcbind
rpcinfo -p localhost

O comando rpcinfo -p deve mostrar pelo menos a porta 2049 (nfs) e 111 (rpcbind). Se a porta 2049 não aparecer, o daemon nfs-server não arrancou correctamente — verifica o journal com journalctl -u nfs-server -e.

3. NFS — Configurar Exportações com /etc/exports

O ficheiro central do servidor NFS é /etc/exports. Cada linha define um directório a partilhar, que clientes podem aceder, e que opções aplicam. O formato é: directorio cliente(opcoes). Cria o directório que vais partilhar e define as permissões adequadas:

sudo mkdir -p /srv/nfs/partilha
sudo chown nobody:nogroup /srv/nfs/partilha
sudo chmod 755 /srv/nfs/partilha

Agora edita o ficheiro /etc/exports com uma linha por exportação. Os exemplos abaixo cobrem os cenários mais comuns — escolhe o que se adequa à tua rede. As opções rw (read-write), ro (read-only), sync (escreve para disco antes de responder, mais seguro), no_subtree_check (desactiva verificação de subtree, melhora desempenho), e no_root_squash são as mais usadas.

# /etc/exports
# Partilha para uma rede especifica (192.168.1.0/24)
/srv/nfs/partilha   192.168.1.0/24(rw,sync,no_subtree_check)

# Partilha de leitura apenas para todos
/srv/nfs/publico   *(ro,sync,no_subtree_check)

# Partilha com no_root_squash (root mantem UID 0)
/srv/nfs/dados    192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

# NFSv4 com fsid=0 (pseudoroot, util para single namespace)
/srv/nfs           192.168.1.0/24(rw,sync,fsid=0,no_subtree_check)

Root squashing é um mecanismo de segurança crítico: quando o root de um cliente monta a partilha, o NFS mapeia o UID 0 para nobody (UID 65534), impedindo que o root remoto tenha permissões de root no servidor. A opção no_root_squash desactiva esta protecção — só a uses em casos específicos como storage de VMs Proxmox, onde o cliente precisa de operar como root. Em partilhas genéricas de utilizadores, mantém o root_squash (que é o comportamento por omissão).

Depois de editar o ficheiro, aplica as mudanças com exportfs. O comando exportfs -a lê o /etc/exports e exporta tudo; exportfs -v mostra as exportações activas com detalhe:

sudo exportfs -a
sudo exportfs -v

# Output esperado:
# /srv/nfs/partilha  192.168.1.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

Para que as exportações persistam após reinício, o serviço nfs-server já lê o /etc/exports no arranque. Não é necessário outro passo adicional.

4. NFS — Montar Partilhas no Cliente e /etc/fstab

No cliente, instala o pacote NFS cliente (em Debian/Ubuntu é nfs-common, em RHEL é nfs-utils). Cria um ponto de montagem e monta manualmente para testar:

# Instalar cliente
sudo apt install nfs-common      # Debian/Ubuntu
sudo dnf install nfs-utils       # RHEL/Rocky/Alma

# Criar ponto de montagem
sudo mkdir -p /mnt/nfs/partilha

# Montar manualmente para testar
sudo mount -t nfs4 192.168.1.10:/partilha /mnt/nfs/partilha

# Verificar
df -hT /mnt/nfs/partilha
mount | grep nfs

O -t nfs4 força a versão 4 do protocolo. Se usares -t nfs sem versão, o cliente negoceia automaticamente. Para montagem persistente no arranque, adiciona uma linha ao /etc/fstab. As opções soft, timeo e retrans controlam o comportamento quando o servidor fica indisponível — com hard (por omissão) os processos bloqueiam indefinidamente; com soft há timeout e erro de I/O após o número de retransmissões.

# /etc/fstab
# Montagem persistente NFSv4
192.168.1.10:/partilha  /mnt/nfs/partilha  nfs4  rw,soft,timeo=600,retrans=2,_netdev  0  0

# Montagem com hard (mais seguro para dados, bloqueia se servidor cair)
192.168.1.10:/dados    /mnt/nfs/dados     nfs4  rw,hard,timeo=600,_netdev  0  0

A opção _netdev diz ao systemd para só montar depois de a rede estar disponível, evitando timeouts no arranque. Depois de editar o fstab, testa com mount -a e confirma com df -hT.

ℹ Nota: Para montagens não-críticas (partilhas de leitura, ficheiros temporários), usa soft para evitar que processos fiquem pendurados se o servidor NFS cair. Para bases de dados ou ficheiros que não podem ser corrompidos, usa sempre hard com timeo elevado.

Alternativamente, podes usar o automounter (autofs), que monta a partilha a pedido e desmonta após um período de inatividade. Isto evita timeouts no arranque se o servidor NFS estiver em baixo.

sudo apt install autofs     # Debian/Ubuntu
sudo dnf install autofs     # RHEL/Rocky/Alma

# /etc/auto.master
/mnt/nfs    /etc/auto.nfs    --timeout=60

# /etc/auto.nfs
partilha    -fstype=nfs4    192.168.1.10:/partilha

sudo systemctl restart autofs

Com autofs, o directório /mnt/nfs/partilha só é montado quando alguém acede a ele, e desmonta após 60 segundos sem uso.

5. Samba — Instalação e Configuração de uma Partilha

O Samba está disponível em todas as distribuições. O pacote chama-se samba no Debian/Ubuntu e no RHEL/Rocky/Alma. Instala e cria o directório de partilha:

# Debian/Ubuntu
sudo apt update
sudo apt install samba samba-common

# RHEL/Rocky/Alma
sudo dnf install samba samba-common

# Criar directorio de partilha
sudo mkdir -p /srv/samba/partilha
sudo chmod 2775 /srv/samba/partilha
sudo chown root:sambashare /srv/samba/partilha

O bit 2775 activa o SGID, fazendo com que os novos ficheiros herdem o grupo sambashare — essencial para que múltiplos utilizadores possam colaborar no mesmo directório. No RHEL, o grupo chama-se smbshare em vez de sambashare — ajusta conforme a distribuição.

Cria um utilizador Samba. Ao contrário do NFS, o Samba autentica por utilizador e password — não por IP. O utilizador tem de existir no sistema Linux e ser adicionado à base de dados do Samba:

# Criar utilizador de sistema
sudo useradd -M -s /usr/sbin/nologin utilizador1

# Adicionar ao Samba (define password)
sudo smbpasswd -a utilizador1

# Adicionar ao grupo de partilha
sudo usermod -aG sambashare utilizador1

Agora configura o ficheiro principal do Samba: /etc/samba/smb.conf. Faz primeiro um backup do original, depois edita. A configuração abaixo cria uma partilha acessível por utilizadores autenticados, com suporte a escrita e ficheiros visíveis a todos os utilizadores do grupo:

# /etc/samba/smb.conf

[global]
   workgroup = WORKGROUP
   server role = standalone server
   security = user
   map to guest = never
   server min protocol = SMB2
   server string = File Server Linux
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file

[partilha]
   path = /srv/samba/partilha
   comment = Partilha de Ficheiros
   browseable = yes
   read only = no
   writable = yes
   valid users = @sambashare
   force group = sambashare
   create mask = 0664
   directory mask = 2775
   inherit permissions = yes

Explicação das opções principais: security = user exige autenticação; map to guest = never proíbe acesso anónimo; server min protocol = SMB2 bloqueia o SMB1 inseguro (descontinuado pela Microsoft em 2017); valid users = @sambashare limita a partilha a membros do grupo; force group garante que os ficheiros criados ficam no grupo certo; create mask e directory mask definem as permissões Unix dos ficheiros novos.

Testa a configuração antes de aplicar — o Samba inclui um validador que detecta erros de sintaxe:

testparm

# Output esperado (no fim):
# Loaded services file OK.
# Server role: ROLE_STANDALONE

Se o testparm reportar erros, corrige antes de continuar. Reinicia os serviços do Samba:

sudo systemctl enable --now smbd nmbd
sudo systemctl restart smbd nmbd

No RHEL/Rocky/Alma, o serviço chama-se smb e nmb (sem o “d” no fim):

sudo systemctl enable --now smb nmb
sudo systemctl restart smb nmb

6. Samba — Acesso de Clientes Linux e Windows

Num cliente Windows, abre o Explorador de Ficheiros e escreve na barra de endereço: \\192.168.1.10\partilha. O Windows pede as credenciais do utilizador Samba criado no passo anterior. Marca “Memorizar credenciais” para não ter de as introduzir a cada acesso. Para mapear a partilha como unidade de rede persistente, usa o comando net use na linha de comandos (cmd) do Windows:

net use Z: \\192.168.1.10\partilha /persistent:yes /user:utilizador1

Num cliente Linux, instala o pacote cliente (cifs-utils) e monta a partilha. O protocolo CIFS é o usado para montar partilhas Samba/Windows em Linux:

sudo apt install cifs-utils     # Debian/Ubuntu
sudo dnf install cifs-utils     # RHEL/Rocky/Alma

# Criar ponto de montagem
sudo mkdir -p /mnt/samba/partilha

# Montar manualmente
sudo mount -t cifs //192.168.1.10/partilha /mnt/samba/partilha \
  -o username=utilizador1,uid=$(id -u),gid=$(id -g),iocharset=utf8

As opções uid e gid mapeiam o dono dos ficheiros montados para o utilizador local — sem isto, os ficheiros aparecem como pertencendo a root. Para montagem persistente no fstab, é boa prática guardar as credenciais num ficheiro separado com permissões restritas:

# Criar ficheiro de credenciais
sudo nano /etc/samba/credentials.txt
username=utilizador1
password=Segred0!
domain=WORKGROUP
# Proteger o ficheiro de credenciais
sudo chmod 600 /etc/samba/credentials.txt
sudo chown root:root /etc/samba/credentials.txt
# /etc/fstab
//192.168.1.10/partilha  /mnt/samba/partilha  cifs  credentials=/etc/samba/credentials.txt,uid=1000,gid=1000,iocharset=utf8,_netdev,x-systemd.automount  0  0

A opção x-systemd.automount faz com que o systemd monte a partilha apenas quando acedida, evitando timeouts no arranque se o servidor Samba estiver em baixo. Testa com sudo mount -a e verifica com df -hT.

7. Firewall e SELinux/AppArmor

Sem firewall configurada, o NFS e o Samba estão acessíveis a toda a rede. Num servidor de produção, restringe o acesso apenas às redes que precisam. As portas a abrir são:

Protocolo Portas Serviço
NFS v4 2049 TCP nfs-server
NFS v3 (legacy) 111 TCP/UDP, 2049 TCP/UDP, 20048 TCP/UDP rpcbind, mountd
Samba 445 TCP, 139 TCP, 137-138 UDP smbd, nmbd

Configura o UFW (Ubuntu/Debian) para permitir apenas a rede interna:

# UFW (Ubuntu/Debian) - NFS
sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp
sudo ufw reload

# UFW - Samba
sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 139 proto tcp
sudo ufw reload
# firewalld (RHEL/Rocky/Alma) - NFS
sudo firewall-cmd --permanent --add-service=nfs --zone=internal
sudo firewall-cmd --permanent --add-service=rpc-bind --zone=internal
sudo firewall-cmd --reload

# firewalld - Samba
sudo firewall-cmd --permanent --add-service=samba --zone=internal
sudo firewall-cmd --reload

No RHEL/Rocky/Alma com SELinux activo, é necessário configurar contextos adicionais para o Samba aceder a directórios fora das localizações padrão. Sem isto, o SELinux bloqueia o acesso mesmo com permissões Unix correctas:

# SELinux - permitir Samba em /srv/samba
sudo semanage fcontext -a -t samba_share_t "/srv/samba(/.*)?"
sudo restorecon -Rv /srv/samba

# SELinux - permitir NFS em /srv/nfs
sudo semanage fcontext -a -t nfsd_Export_t "/srv/nfs(/.*)?"
sudo restorecon -Rv /srv/nfs

# Verificar contextos
ls -Zd /srv/samba /srv/nfs

No Ubuntu/Debian, o AppArmor pode bloquear o Samba se o directório estiver fora dos caminhos permitidos no perfil. Verifica os logs em /var/log/syslog ou dmesg | grep apparmor se houver problemas de acesso.

8. Erros Comuns

A tabela seguinte reúne os problemas mais frequentes em ambientes reais, com a causa directa e a solução aplicável:

Problema Causa Solução
mount.nfs: access denied by server IP do cliente não está na lista de exports Adicionar IP/rede em /etc/exports, correr exportfs -a
mount.nfs: Connection timed out Firewall a bloquear porta 2049 ou servidor em baixo Verificar firewall, testar com nc -zv servidor 2049
Permissões negadas ao escrever (NFS) root_squash mapeia root para nobody; UID mismatch entre cliente e servidor Sincronizar UIDs via LDAP/NIS, ou usar no_root_squash se apropriado
NT_STATUS_ACCESS_DENIED no Samba Utilizador não criado com smbpasswd -a, ou não no grupo sambashare sudo smbpasswd -a user; sudo usermod -aG sambashare user
Ficheiros aparecem como nobody/nogroup all_squash activo ou mapeamento de UID incorrecto Remover all_squash; garantir UIDs consistentes cliente-servidor
smbd não arranca após editar smb.conf Erro de sintaxe no ficheiro de configuração Correr testparm para identificar o erro, corrigir, reiniciar smbd
Sistema bloqueia ao desligar (NFS hard mount) Mount hard sem servidor disponível; systemd espera indefinidamente Usar _netdev e x-systemd.automount, ou soft para partilhas não-críticas
SELinux impede acesso Samba a /srv Contexto SELinux incorrecto no directório semanage fcontext + restorecon, ou setsebool -P samba_export_all_rw on

9. Checklist de Verificação

Antes de considerar o servidor pronto para produção, confirma cada um destes pontos:

  1. Serviços activos: systemctl is-active nfs-server smbd nmbd — todos devem retornar “active”.
  2. Exports NFS visíveis: exportfs -v mostra todas as partilhas com as opções correctas.
  3. Configuração Samba válida: testparm -s não reporta erros.
  4. Firewall configurada: Apenas a rede interna consegue aceder às portas 2049 (NFS) e 445 (Samba).
  5. Teste de montagem NFS: Cliente monta com mount -t nfs4 e consegue criar/ler ficheiros.
  6. Teste de acesso Samba: Cliente Windows acede a \\servidor\partilha com credenciais e consegue escrever.
  7. Permissões consistentes: Ficheiros criados por um utilizador são acessíveis por outros membros do grupo (verificar com ls -la).
  8. SELinux/AppArmor: Sem negações nos logs (grep denied /var/log/audit/audit.log).
  9. fstab persistente: mount -a corre sem erros; reinício de teste monta tudo.
  10. Idempotência: Após reiniciar o servidor, os serviços arrancam automaticamente e os clientes voltam a montar.
⚠ Atenção: Uma configuração incorrecta de exports NFS ou de permissões Samba pode expor ficheiros sensíveis a toda a rede. Sempre que alterares o /etc/exports ou o smb.conf, corre exportfs -v e testparm e verifica a partir de um cliente que apenas os utilizadores autorizados conseguem aceder.

Artigos Relacionados