Installer Samba 4 sur Debian sans ouvrir un partage fragile

Samba 4 peut servir un dossier partagé ou jouer le rôle de contrôleur Active Directory. Ces deux scénarios n’ont pas le même niveau de risque. Pour un NAS maison, un dossier domotique, un partage de sauvegardes ou un petit bureau, le mode standalone suffit dans la majorité des cas.

Le contrôleur AD DC ajoute DNS, Kerberos, annuaire, jonction de postes et politiques de domaine. C’est utile si vous voulez centraliser une flotte de machines, pas si vous voulez seulement accéder à \\serveur\domotique. Mélanger les deux dès le départ complique les logs, les ports ouverts et la sauvegarde.

La première décision tient donc en une phrase : je veux un partage de fichiers, pas une infrastructure d’identité.

Avant Samba, stabilisez le serveur. Une réservation DHCP côté routeur est souvent plus propre qu’une IP statique bricolée sur Debian, à condition qu’elle soit documentée. L’important est que les clients retrouvent toujours la même adresse réseau.

Mettez ensuite le système à jour. Sur une machine qui sert déjà des fichiers, faites-le pendant une fenêtre où un redémarrage ne pose pas problème.

sudo apt update
sudo apt upgrade

Installez Samba et smbclient. Le premier sert les partages, le second permet de tester depuis le serveur lui-même. C’est le test le plus rapide quand un client Windows vous renvoie une erreur vague.

sudo apt install samba smbclient

Contrôlez la version et le service principal. Pour un partage SMB classique, le service à surveiller est smbd. nmbd peut aider certains vieux mécanismes de découverte, mais il ne doit pas devenir votre diagnostic par défaut.

smbd --version
systemctl status smbd --no-pager

Samba ne répare pas des permissions Linux incohérentes. Si le système de fichiers refuse l’écriture, l’authentification SMB peut réussir et l’utilisateur échouera quand même au moment de créer un fichier. C’est le faux positif classique.

Créez un groupe dédié, puis le dossier partagé. Ici, le groupe s’appelle sambashare et le chemin est /srv/samba/domotique. Adaptez le nom du partage, pas la logique.

sudo groupadd --force sambashare
sudo mkdir -p /srv/samba/domotique
sudo chgrp sambashare /srv/samba/domotique
sudo chmod 2770 /srv/samba/domotique

Le 2 de 2770 pose le bit setgid sur le répertoire. Les fichiers créés dessous gardent le groupe du dossier, ce qui évite qu’un utilisateur crée un fichier impossible à modifier par les autres membres du partage.

Un compte Samba s’appuie sur un utilisateur Linux existant, mais son mot de passe SMB se gère séparément. C’est pratique pour isoler l’accès réseau; c’est aussi une source d’erreur si vous pensez que changer le mot de passe Linux suffit.

Créez ou réutilisez un utilisateur, puis ajoutez-le au groupe du partage. Exemple avec nicolas. Après ajout au groupe, une reconnexion de session peut être nécessaire pour que les groupes soient visibles dans un shell interactif.

sudo adduser nicolas
sudo usermod -aG sambashare nicolas
id nicolas

Ajoutez ensuite le mot de passe Samba et activez le compte. smbpasswd modifie la base d’identifiants Samba; il ne remplace pas la gestion des utilisateurs Linux.

sudo smbpasswd -a nicolas
sudo smbpasswd -e nicolas

À ce stade, vous devez pouvoir expliquer trois choses sans hésiter : quel compte se connecte, à quel groupe il appartient, et quel dossier porte ce groupe.

Sauvegardez toujours /etc/samba/smb.conf avant modification. Une configuration Samba doit pouvoir revenir en arrière en trente secondes, surtout si le serveur héberge déjà d’autres partages.

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

Dans [global], gardez une intention claire. server role = standalone server documente le choix. map to guest = never et usershare allow guests = no évitent les contournements silencieux vers un accès invité.

[global]
   workgroup = WORKGROUP
   server role = standalone server
   map to guest = never
   usershare allow guests = no
   log file = /var/log/samba/log.%m
   max log size = 1000

Ajoutez ensuite le partage. Les paramètres importants sont valid users, force group, create mask et directory mask. Ils alignent la couche Samba avec les droits du dossier Linux.

[domotique]
   comment = Partage domotique local
   path = /srv/samba/domotique
   browseable = yes
   read only = no
   guest ok = no
   valid users = @sambashare
   force group = sambashare
   create mask = 0660
   directory mask = 2770

Cette configuration ne cherche pas à tout couvrir. Elle vise un partage local propre, sans imprimantes, sans homes automatiques et sans invités. C’est plus simple à relire, donc plus simple à dépanner quand une mise à jour de client, un changement de mot de passe ou une migration de disque modifie le comportement attendu. Moins de paramètres, plus de preuves.

testparm est le garde-fou. Il vérifie la cohérence interne de smb.conf et retourne une erreur si la configuration ne peut pas être chargée correctement. Il ne garantit pas que votre client aura accès au partage, mais il élimine déjà la faute de syntaxe.

testparm /etc/samba/smb.conf

Si le chargement est correct, redémarrez smbd puis contrôlez son état. Ne passez pas au client tant que le service n’est pas stable.

sudo systemctl restart smbd
systemctl status smbd --no-pager

Ouvrez ensuite le pare-feu seulement si vous l’utilisez. Sur un serveur accessible depuis plusieurs VLAN ou depuis un VPN, limitez l’exposition au réseau qui doit réellement accéder au partage. SMB n’a rien à faire ouvert sur Internet.

sudo ufw allow from 192.168.1.0/24 to any app Samba

Le premier test se fait localement avec smbclient. Il valide que Samba publie le partage et accepte l’utilisateur. Utilisez l’IP ou le nom DNS local que les clients utiliseront vraiment.

smbclient -L //localhost -U nicolas
smbclient //localhost/domotique -U nicolas

Dans la session smbclient, créez un fichier de test, listez le répertoire, puis supprimez-le. Vous vérifiez l’authentification, l’écriture et la lecture sans dépendre de l’explorateur Windows.

put test.txt
ls
rm test.txt

Depuis Windows, ouvrez \\IP_DU_SERVEUR\domotique. Depuis Linux, utilisez le gestionnaire de fichiers ou montez le partage avec cifs-utils si vous avez besoin d’un montage persistant. Depuis macOS, le chemin sera du type smb://IP_DU_SERVEUR/domotique.

Le test important n’est pas seulement l’ouverture du dossier. Créez un fichier depuis chaque client, fermez la session, reconnectez-vous et modifiez le fichier créé par un autre utilisateur du groupe. C’est là que les erreurs de masque de création et de groupe ressortent.

Validation

Les deux tests qui évitent 80 % des faux diagnostics

Un partage SMB doit être validé par couche, pas seulement ouvert une fois dans un explorateur.

Tester localement

smbclient confirme la publication du partage, l’authentification et les premières opérations de fichier.

Tester les vrais clients

Windows, Linux ou macOS doivent écrire, relire et modifier un fichier créé par un autre membre du groupe.

Si un poste Linux doit accéder au partage tous les jours, évitez de cliquer manuellement dans le gestionnaire de fichiers. Installez cifs-utils et préparez un montage explicite. Le piège, ici, n’est pas la syntaxe CIFS; c’est de bloquer le démarrage parce qu’un portable est hors du réseau ou parce que le serveur Debian n’est pas encore disponible.

sudo apt install cifs-utils
sudo mkdir -p /mnt/domotique

Stockez les identifiants dans un fichier lisible uniquement par root. C’est moins mauvais que de laisser un mot de passe en clair dans /etc/fstab, mais cela reste un secret local. Sur un poste partagé ou peu maîtrisé, posez-vous la question avant de créer un montage automatique.

sudo nano /root/.smb-domotique
sudo chmod 600 /root/.smb-domotique

username=nicolas
password=mot-de-passe-samba

Dans /etc/fstab, ajoutez une ligne prudente avec nofail et x-systemd.automount. Cette combinaison laisse la machine démarrer même si le partage est absent, puis monte le dossier à la première utilisation. C’est le comportement le plus sain pour un laptop, un mini PC domotique ou une machine qui redémarre avant le serveur de fichiers.

//192.168.1.20/domotique /mnt/domotique cifs credentials=/root/.smb-domotique,uid=1000,gid=1000,iocharset=utf8,nofail,x-systemd.automount 0 0

Testez ensuite sans redémarrer. Si la commande échoue, vous pouvez corriger immédiatement sans laisser une entrée cassée dans un cycle de boot.

sudo mount -a
findmnt /mnt/domotique

Si l’authentification échoue, commencez par le compte. Vérifiez que l’utilisateur existe côté Linux, qu’il est activé côté Samba et qu’il appartient au bon groupe. Une erreur de mot de passe Samba ressemble souvent à un problème réseau, alors qu’elle n’en est pas un.

id nicolas
sudo pdbedit -L
sudo smbpasswd -e nicolas

Si la connexion réussit mais l’écriture échoue, regardez les droits Linux avant smb.conf. Le dossier doit appartenir au groupe attendu et conserver le setgid. Le couple chgrp + chmod 2770 règle plus de cas que la plupart des options Samba exotiques.

ls -ld /srv/samba/domotique
namei -l /srv/samba/domotique

Si le partage n’apparaît pas dans l’explorateur réseau, testez l’accès direct par chemin UNC ou par IP. La découverte réseau est un confort, pas une preuve. Un partage peut fonctionner parfaitement sans apparaître automatiquement dans la liste.

• Accès refusé : utilisateur absent du groupe, compte Samba non activé ou mauvais mot de passe.
• Lecture OK, écriture KO : droits Linux, setgid, create mask ou directory mask incohérents.
• Partage invisible : découverte réseau, DNS local ou nom NetBIOS; testez l’IP avant de modifier Samba.
• Configuration qui ne charge pas : lancez testparm, corrigez la ligne indiquée, puis redémarrez smbd.

La sécurité utile reste simple : pas d’invités, un groupe dédié, des comptes nominatifs, une exposition limitée au LAN et une sauvegarde de la configuration. Si vous avez plusieurs partages, évitez de tout mettre dans un seul groupe fourre-tout. Les droits doivent refléter les usages réels.

Sur un réseau domotique, gardez aussi une frontière claire entre les services. Un serveur qui héberge Home Assistant, MQTT, des sauvegardes et un partage familial ne doit pas exposer SMB à tous les VLAN sans raison. L’accès au partage se pilote comme le reste : besoin réel, réseau autorisé, compte identifié, journal de changement et suppression des comptes de test quand l’installation est validée, surtout si des automatisations déposent des exports ou des sauvegardes dans le même espace.

Le risque discret, dans un home lab, vient souvent des exceptions empilées. On ouvre un partage à un vieux PC, puis à une VM de test, puis à un conteneur qui n’en avait besoin qu’une semaine. Six mois plus tard, personne ne sait plus quel client écrit où. Un partage Samba maintenable doit donc avoir une liste courte de clients autorisés, des comptes supprimés quand ils ne servent plus et une vérification périodique des fichiers créés avec le mauvais propriétaire.

Avant de considérer l’installation terminée, notez quatre informations dans votre documentation locale : IP ou nom DNS, chemin du dossier, groupe Linux, emplacement de la sauvegarde smb.conf. C’est le minimum de rollback quand une mise à jour ou un changement de client casse l’accès.

Gardez aussi une copie datée de la configuration qui fonctionne. Après chaque modification importante, sauvegardez smb.conf, notez le motif et relancez testparm. Si une option ajoutée pour un client casse les autres, vous devez pouvoir revenir au dernier état validé, pas reconstruire la configuration à partir de souvenirs.

Mon verdict : pour un partage de fichiers Debian propre, restez en standalone, gardez smb.conf court, testez avec testparm puis smbclient, et refusez les accès invités tant que vous n’avez pas une raison documentée. C’est moins spectaculaire qu’un AD DC, mais c’est beaucoup plus maintenable dans un home lab ou une petite installation.