Samba no Ubuntu Server: compartilhe arquivos com o Windows

O Samba é o serviço que faz um servidor Linux falar SMB/CIFS, o protocolo nativo de compartilhamento de arquivos do Windows. Ele resolve o problema mais comum em rede mista: colocar uma pasta em um Ubuntu Server e deixar estações Windows acessarem como um compartilhamento de rede normal, com login e permissão por usuário — não uma pasta aberta para qualquer um.

Este guia configura um compartilhamento restrito por grupo em um Ubuntu Server 24.04 ou 26.04 LTS, com autenticação própria do Samba, firewall liberado só nas portas necessárias e acesso tanto pelo Windows quanto por outro Linux.

Instalando o Samba

O pacote samba traz o smbd (serviço que atende os compartilhamentos de arquivo), o nmbd (resolução de nomes via NetBIOS, usado por clientes Windows mais antigos) e utilitários como smbpasswd e testparm.

sudo apt update
sudo apt install samba -y

Confirme que o serviço subiu:

sudo systemctl status smbd

Criando o grupo, o usuário e a pasta compartilhada

Em vez de liberar a pasta para qualquer usuário do sistema, crie um grupo dedicado. Assim, dar ou tirar acesso de alguém vira só adicionar ou remover do grupo — sem editar o smb.conf a cada mudança de equipe.

1. Crie o grupo e adicione o usuário que vai acessar o compartilhamento:

   sudo groupadd equipe-ti
   sudo usermod -aG equipe-ti ana

2. Crie a pasta e ajuste dono e permissões:

   sudo mkdir -p /srv/samba/ti
   sudo chown root:equipe-ti /srv/samba/ti
   sudo chmod 2770 /srv/samba/ti

   O 2770 tem dois efeitos: o 770 bloqueia acesso de qualquer um fora do grupo equipe-ti, e o bit setgid (o 2 inicial) faz todo arquivo novo criado ali herdar o grupo da pasta — sem isso, cada usuário criaria arquivos com seu próprio grupo primário e a permissão de equipe quebraria aos poucos.

Criando o usuário no banco de senhas do Samba

O Samba mantém uma base de autenticação separada da do Linux — o usuário do sistema precisa existir primeiro, mas a senha usada para acessar o compartilhamento é definida à parte:

sudo smbpasswd -a ana

Confirme que o usuário foi criado:

sudo pdbedit -L

Configurando o smb.conf

Faça backup do arquivo original antes de mexer:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

No bloco [global], confirme (ou ajuste) estas linhas:

workgroup = WORKGROUP
security = user
map to guest = bad user

security = user exige usuário e senha válidos do Samba para qualquer acesso. map to guest = bad user garante que uma senha errada seja rejeitada, mesmo que o nome de usuário exista — sem essa linha, algumas versões do Samba tratam login malsucedido como acesso anônimo.

No final do arquivo, adicione o compartilhamento:

[ti]
   path = /srv/samba/ti
   valid users = @equipe-ti
   guest ok = no
   read only = no
   create mask = 0660
   directory mask = 2770

valid users = @equipe-ti restringe o acesso a quem está no grupo — o @ antes do nome indica grupo, não usuário. create mask e directory mask replicam o esquema de permissão 660/2770 independentemente do umask configurado na máquina cliente que está gravando o arquivo.

Valide a sintaxe e reinicie os serviços:

sudo testparm
sudo systemctl restart smbd nmbd

Liberando no firewall (ufw)

sudo ufw allow Samba

Esse perfil abre as portas 137/udp e 138/udp (NetBIOS), 139/tcp (sessão NetBIOS) e 445/tcp (SMB direto sobre TCP, usado por clientes modernos). No Ubuntu 26.04 o NetBIOS vem desabilitado por padrão (disable netbios = yes) — se você manteve esse padrão, libere só a 445/tcp e não abra 137-139 à toa, já que é superfície de ataque de um protocolo legado.

Acessando pelo Windows

1. Abra o Explorer e digite \\IP-DO-SERVIDOR\ti na barra de endereço.
2. Informe o usuário (ana) e a senha definida no smbpasswd.
3. Para deixar fixo, clique com o botão direito em “Este Computador” → Mapear unidade de rede e marque “Reconectar ao entrar”.

Se o Windows não encontrar o servidor pelo nome, use o IP direto — o Explorer moderno depende cada vez menos de NetBIOS para descoberta automática na rede.

Montando o compartilhamento em outro Linux

sudo apt install cifs-utils -y

Crie um arquivo de credenciais em vez de colocar usuário e senha direto no fstab:

sudo nano /etc/samba/credentials-ti

username=ana
password=SENHA-DA-ANA
domain=WORKGROUP

sudo chmod 600 /etc/samba/credentials-ti

Adicione a entrada no /etc/fstab:

//IP-DO-SERVIDOR/ti /mnt/ti cifs credentials=/etc/samba/credentials-ti,uid=1000,gid=1000,file_mode=0660,dir_mode=2770,vers=3.0 0 0

sudo mkdir -p /mnt/ti
sudo mount -a

O parâmetro vers=3.0 força o protocolo SMB3 e evita que o cliente caia para SMB1 — versão sem suporte a criptografia e alvo de falhas antigas como a explorada pelo WannaCry.

Perguntas frequentes

smbd e nmbd fazem a mesma coisa?
Não. O smbd atende os compartilhamentos de arquivo e impressora em si; o nmbd só responde por resolução de nome NetBIOS, útil para clientes Windows mais antigos ou redes sem DNS interno.

É seguro deixar a porta 445 aberta para a internet?
Não. SMB nunca deve ser exposto diretamente à internet — mantenha o acesso restrito à rede local ou atrás de VPN. A porta já foi vetor de exploits críticos como EternalBlue.

Por que usar grupo em vez de liberar o compartilhamento para qualquer usuário?
Porque gerenciar acesso por grupo (valid users = @equipe-ti) significa que adicionar ou remover uma pessoa é um usermod, sem tocar no smb.conf nem reiniciar o serviço.

Dá para usar o mesmo Samba para entrar em um domínio Active Directory?
Sim, mas é outro modo de operação (security = ads, com realm e ingresso no domínio via net ads join) — foge do escopo de um compartilhamento standalone como este.

O que fazer se o Windows pedir senha em loop e nunca aceitar?
Geralmente é usuário/senha do Samba divergente do Windows, ou uma credencial antiga salva no Gerenciador de Credenciais do Windows. Limpe a credencial salva (Painel de Controle → Gerenciador de Credenciais) e tente de novo.

Conclusão

Com o compartilhamento restrito por grupo, autenticação própria do Samba e firewall liberado só nas portas necessárias, o servidor fica pronto para produção — sem pasta aberta para qualquer um na rede. Para redes maiores, o próximo passo natural é avaliar ingresso em um domínio Active Directory ou LDAP centralizado, em vez de manter a base de usuários local em cada servidor Samba.