Samba sous Debian : construire un serveur de fichiers SMB proprement

Vous êtes sous Debian, vous avez des fichiers et, contre toute attente, vous souhaitez permettre à d’autres machines d’y accéder.

Windows est dans les parages. Peut-être quelques Linux. Éventuellement un macOS. Tout ce petit monde doit consulter les mêmes documents sans que vous déposiez une clé USB sur chaque bureau comme un facteur particulièrement mal payé.

C’est précisément le genre de problème que Samba résout depuis des décennies.

Samba permet à une machine Unix ou Linux de fournir des services compatibles avec le protocole SMB — Server Message Block, utilisé notamment par Windows pour le partage de fichiers et d’imprimantes.

Avec Samba, votre Debian peut se comporter comme un serveur de fichiers SMB parfaitement naturel pour les postes Windows.

Bien configuré, le résultat est remarquablement banal :

\\serveur\documents

Les utilisateurs voient leurs fichiers.

Ils ignorent les UID, les ACL, les démons, les dialectes SMB et les heures que vous avez passées à découvrir pourquoi Bob pouvait ouvrir un document mais pas le modifier.

C’est généralement le signe que l’administrateur a bien travaillé.

Qu’est-ce que Samba ?

Samba est un ensemble de logiciels libres qui implémentent les protocoles et services nécessaires à l’interopérabilité avec les environnements Windows.

Il peut notamment servir à :

• partager des fichiers ;
• partager des imprimantes ;
• authentifier des utilisateurs ;
• intégrer une machine Linux à un domaine Active Directory ;
• fournir certains services de domaine ;
• et même fonctionner comme contrôleur de domaine Active Directory dans une architecture appropriée.

Dans cet article, nous nous concentrons sur le cas le plus simple et le plus fréquent :

transformer une machine Debian en serveur de fichiers SMB autonome.

Pas de contrôleur de domaine.

Pas de forêt Active Directory composée de quatre sites et d’un DNS qui a connu la guerre.

Juste des utilisateurs, des dossiers et des permissions correctement administrées.

SMB et CIFS : une précision historique importante

On rencontre encore très souvent l’expression :

SMB/CIFS

Elle est compréhensible historiquement, mais il vaut mieux comprendre ce qu’elle recouvre.

SMB est la famille du protocole.

CIFS — Common Internet File System désigne essentiellement une évolution historique de SMB associée au dialecte que Samba nomme NT1, c’est-à-dire à l’univers que l’on regroupe aujourd’hui sous SMB1.

CIFS n’est donc pas « le SMB moderne ».

C’est plutôt l’un de ses ancêtres particulièrement bavards.

Les générations principales

Famille	Époque / usage	Situation actuelle
SMB1 / CIFS	Windows anciens, équipements historiques	Obsolète et généralement à éviter
SMB2	Introduit avec Windows Vista / Server 2008	Toujours pris en charge
SMB3	Introduit avec Windows 8 / Server 2012 puis enrichi	Famille moderne

SMB2 et SMB3 apportent notamment une architecture beaucoup plus efficace que SMB1 et de nombreuses fonctions modernes.

SMB3 ajoute également des capacités comme le chiffrement du trafic dans les versions compatibles.

Ne réactivez pas SMB1 juste parce qu’un vieux périphérique boude

Sur un Samba moderne, la négociation normale permet aux clients et au serveur de choisir automatiquement un dialecte compatible.

Il n’est généralement pas nécessaire d’ajouter :

server min protocol = SMB2

simplement pour « sécuriser Samba » sur une installation Debian actuelle : les versions modernes possèdent déjà une version minimale SMB2 par défaut.

En revanche, évitez de faire ceci :

server min protocol = NT1

uniquement parce qu’un appareil de 2009 refuse de se connecter.

Si votre scanner réclame SMB1, la question pertinente est :

« Comment isoler ou remplacer ce scanner ? »

et non :

« Comment faire revenir tout mon serveur de fichiers en 1998 ? »

Les principaux composants de Samba

Pour un serveur de fichiers autonome, plusieurs programmes peuvent entrer en jeu.

smbd : le cœur du serveur de fichiers

smbd fournit les services SMB aux clients.

Il s’occupe notamment :

• des connexions SMB ;
• de l’authentification dans les modes appropriés ;
• du partage des fichiers ;
• des permissions ;
• des verrous de fichiers ;
• des attributs ;
• et des opérations effectuées par les clients.

Pour notre serveur de fichiers, c’est lui qui fait le vrai travail.

nmbd : le vétéran NetBIOS

nmbd gère principalement des fonctions historiques liées à NetBIOS over TCP/IP :

• résolution de noms NetBIOS ;
• annonces réseau historiques ;
• browsing SMB ancien ;
• WINS lorsqu’il est configuré pour cela.

Il reste fourni sous Debian et peut être utile dans certains réseaux anciens.

Mais un client moderne qui accède directement à :

\\fileserver.example.lan\documents

via DNS et SMB2/SMB3 n’a pas besoin du vieux mécanisme de navigation NetBIOS pour que le partage fonctionne.

nmbd est donc davantage l’archiviste du quartier que le moteur principal du serveur moderne.

winbindd : quand Active Directory entre dans la pièce

winbindd est particulièrement important lorsqu’un serveur Samba doit intégrer des utilisateurs et groupes provenant d’un domaine Windows ou Active Directory.

Il peut notamment participer à la correspondance entre :

• SID Windows ;
• UID Unix ;
• GID Unix ;
• utilisateurs du domaine ;
• groupes du domaine.

Pour notre serveur autonome avec comptes locaux, il n’est pas nécessaire d’en faire le centre de l’article.

Et le service samba-ad-dc ?

Un contrôleur de domaine Samba Active Directory utilise une architecture différente.

Ne prenez donc pas un tutoriel destiné à un simple :

smbd

et ne l’appliquez pas aveuglément à un contrôleur de domaine.

Les deux machines utilisent Samba.

Comme un vélo et un semi-remorque utilisent tous deux des roues.

Le reste mérite tout de même quelques adaptations.

Installation sous Debian

Actualisons d’abord les index APT :

sudo apt update

Puis installons Samba ainsi que le client en ligne de commande qui nous servira pour les tests :

sudo apt install samba smbclient

Le fichier principal de configuration se trouve normalement dans :

/etc/samba/smb.conf

Sauvegarder la configuration avant d’y toucher

Avant la moindre modification :

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

Ce n’est pas spectaculaire.

Ce n’est pas particulièrement technique.

Mais une copie d’un fichier fonctionnel devient étonnamment séduisante environ trente secondes après avoir supprimé par accident une section entière.

Vérifier le service

Pour le serveur de fichiers :

systemctl status smbd

Et si vous utilisez également le service NetBIOS historique :

systemctl status nmbd

On peut aussi afficher les deux :

systemctl status smbd nmbd

La structure de smb.conf

Le fichier utilise des sections.

La section :

[global]

contient les paramètres généraux.

Puis chaque partage possède généralement sa propre section :

[documents]
   path = /srv/samba/documents

Le nom entre crochets devient le nom du partage visible sur le réseau.

Ainsi :

[documents]

produit typiquement :

\\serveur\documents

Configuration globale minimale pour un serveur autonome

Pour un serveur local simple avec authentification utilisateur :

[global]
   workgroup = WORKGROUP
   server role = standalone
   security = user

server role = standalone indique que la machine fonctionne comme serveur autonome.

security = user correspond à une authentification basée sur les utilisateurs.

Dans ce mode, les comptes sont authentifiés par Samba puis associés à des identités Unix locales.

WORKGROUP n’est pas un domaine Active Directory

Le paramètre :

workgroup = WORKGROUP

correspond notamment au groupe de travail SMB/NetBIOS utilisé dans les environnements classiques.

Ce n’est pas la même chose qu’un domaine DNS comme :

example.lan

et ce n’est pas non plus une configuration Active Directory complète.

Trois concepts peuvent porter des noms similaires.

Windows estime manifestement que l’administrateur n’avait pas suffisamment de choses à distinguer.

Créer le répertoire à partager

Créons notre espace de données :

sudo mkdir -p /srv/samba/documents

Le répertoire :

/srv/samba

est un choix cohérent pour des données fournies par un service.

Ce n’est pas une obligation absolue, mais cela évite d’héberger le service de fichiers dans :

/home/alice/Bureau/Nouveau dossier (3)

ce qui constitue déjà un progrès architectural significatif.

Créer les utilisateurs Linux

Pour qu’un compte Samba local soit utilisable avec le backend standard, il doit normalement correspondre à un utilisateur Unix connu du système.

Pour un utilisateur Linux classique :

sudo adduser alice
sudo adduser bob

Si ces comptes servent uniquement à Samba et ne doivent pas ouvrir de session shell, on peut créer des comptes adaptés à cet usage.

Par exemple :

sudo useradd -M -s /usr/sbin/nologin alice
sudo useradd -M -s /usr/sbin/nologin bob

-M évite ici la création automatique d’un répertoire personnel.

/usr/sbin/nologin empêche une connexion shell classique.

Samba peut néanmoins utiliser l’identité Unix pour accéder aux fichiers.

Créer un groupe pour le partage

sudo groupadd sambadocs

Puis ajoutons les utilisateurs :

sudo usermod -aG sambadocs alice
sudo usermod -aG sambadocs bob

Attribuons le répertoire au groupe :

sudo chown root:sambadocs /srv/samba/documents

Et appliquons des permissions :

sudo chmod 2770 /srv/samba/documents

Pourquoi 2770 ?

Le :

770

accorde :

• lecture, écriture et traversée au propriétaire ;
• lecture, écriture et traversée au groupe ;
• aucun accès aux autres utilisateurs.

Le bit supplémentaire :

2

active le setgid sur le répertoire.

Les nouveaux fichiers et sous-répertoires ont ainsi tendance à conserver le groupe du répertoire parent, ce qui facilite le travail collaboratif.

Sans cela, un partage d’équipe peut rapidement devenir un musée consacré aux groupes primaires personnels de chacun.

Ajouter les comptes dans Samba

Une fois l’utilisateur Unix créé :

sudo smbpasswd -a alice

Puis :

sudo smbpasswd -a bob

La commande demande un mot de passe SMB.

Celui-ci peut être différent du mot de passe Unix.

Où Samba conserve-t-il ses comptes ?

Sur un serveur autonome moderne utilisant la configuration par défaut, Samba emploie généralement le backend :

tdbsam

Les comptes sont alors stockés dans une base TDB appelée :

passdb.tdb

Le répertoire privé par défaut de Samba sous Debian est :

/var/lib/samba/private

On rencontre donc normalement :

/var/lib/samba/private/passdb.tdb

Cette base est distincte du fichier système Linux shadow, situé dans le répertoire /etc.

Samba a besoin de l’identité Unix pour les permissions du système de fichiers, mais gère ses propres données d’authentification SMB.

Deux bases pour un même prénom.

Parce qu’une seule source d’identité aurait rendu le dépannage beaucoup trop rapide.

Lister les comptes Samba

Une commande très pratique est :

sudo pdbedit -L

Pour davantage de détails sur un utilisateur :

sudo pdbedit -L -v alice

Désactiver et réactiver un compte Samba

Désactivation :

sudo smbpasswd -d alice

Réactivation :

sudo smbpasswd -e alice

Supprimer un compte de la base Samba

sudo smbpasswd -x alice

Cela retire le compte Samba.

Cela ne supprime pas automatiquement l’utilisateur Unix correspondant.

Là encore, Samba et Linux tiennent chacun leur propre registre.

Premier partage : Alice écrit, Bob lit

Ajoutons dans :

/etc/samba/smb.conf

la section :

[documents]
   path = /srv/samba/documents
   browseable = yes
   read only = yes
   valid users = alice bob
   write list = alice

Cette configuration reprend le principe initial :

• Alice et Bob ont le droit d’ouvrir le partage ;
• le partage est globalement en lecture seule ;
• Alice fait exception grâce à write list et peut écrire ;
• Bob reste en lecture seule.

valid users : qui a le droit d’entrer ?

Le paramètre :

valid users = alice bob

limite le partage aux comptes indiqués.

On peut également utiliser un groupe Unix avec :

valid users = @sambadocs

Le caractère :

@

permet ici de référencer un groupe.

Pour une administration professionnelle, les groupes sont généralement beaucoup plus pratiques que des listes de quinze utilisateurs saisies à la main.

read only et writable

Le paramètre :

read only = yes

rend normalement le partage non modifiable.

Son inverse peut être exprimé par :

writeable = yes

ou son alias courant :

writable = yes

Pour éviter les doubles négations inutiles, il est souvent plus simple de choisir une convention et de s’y tenir.

Par exemple :

read only = yes

ou :

read only = no

plutôt que de transformer chaque partage en exercice de logique propositionnelle.

write list : une exception d’écriture

Avec :

read only = yes
write list = alice

le partage est normalement en lecture seule, sauf pour Alice.

On peut également utiliser un groupe :

write list = @sambawriters

C’est pratique pour créer une politique :

• beaucoup de lecteurs ;
• quelques rédacteurs.

read list : forcer certains utilisateurs en lecture seule

Le mécanisme inverse existe également :

read list = bob

Il permet de forcer Bob en lecture seule, même si le partage est par ailleurs modifiable.

Par exemple :

[projets]
   path = /srv/samba/projets
   read only = no
   valid users = @projets
   read list = bob

Tous les utilisateurs autorisés peuvent écrire, sauf Bob.

On ignore ce que Bob a fait.

Mais la configuration conserve manifestement une trace administrative de l’incident.

Si un utilisateur est dans read list et write list

Évitez de créer volontairement ce genre d’ambiguïté.

Mais si un utilisateur se trouve dans les deux listes, Samba donne priorité à write list et lui accorde l’écriture.

Il vaut mieux néanmoins construire des groupes dont les rôles sont compréhensibles plutôt que compter sur ce détail pour concevoir toute votre politique de sécurité.

Le système de fichiers Linux a toujours le dernier mot

Une règle fondamentale :

Samba ne peut pas donner à un utilisateur des droits que le système Linux sous-jacent lui refuse.

Vous pouvez écrire :

write list = alice

autant de fois que vous voulez.

Si Linux ne permet pas à Alice d’écrire dans :

/srv/samba/documents

la création d’un fichier échouera.

Deux couches de permissions

Couche	Exemples
Samba	valid users, read only, write list
Linux	UID, GID, chmod, ACL POSIX

L’accès final doit satisfaire les deux.

C’est très similaire au principe permissions de partage + NTFS sous Windows.

Et tout aussi efficace pour produire la célèbre phrase :

« Pourtant j’ai mis les droits dans Samba. »

Attention à notre exemple Alice/Bob

Dans notre exemple :

chmod 2770 /srv/samba/documents

Alice et Bob appartiennent tous les deux au groupe sambadocs.

Le système Unix leur permet donc techniquement tous les deux d’écrire localement dans le répertoire.

C’est Samba qui bloque l’écriture de Bob lorsqu’il passe par le partage SMB.

Si Bob peut se connecter localement à la machine par un autre moyen, cette restriction Samba ne constitue évidemment pas une interdiction Unix globale.

Pour obtenir également une séparation stricte au niveau du système de fichiers, utilisez des groupes distincts ou des ACL POSIX.

Utiliser des ACL Linux pour une politique plus précise

Installons les outils si nécessaire :

sudo apt install acl

On peut alors accorder explicitement :

sudo setfacl -m u:alice:rwx /srv/samba/documents
sudo setfacl -m u:bob:rx /srv/samba/documents

Et définir des ACL par défaut pour les nouveaux éléments :

sudo setfacl -m d:u:alice:rwx /srv/samba/documents
sudo setfacl -m d:u:bob:rx /srv/samba/documents

Vérification :

getfacl /srv/samba/documents

Les ACL permettent des politiques beaucoup plus précises que les trois blocs traditionnels :

user
group
other

Elles permettent aussi de produire des sorties assez longues pour rappeler que toute flexibilité possède un prix.

Exemple avec groupes

Une approche plus propre pour une équipe consiste à créer :

samba-docs-read
samba-docs-write

Puis à gérer les utilisateurs dans ces groupes.

La configuration Samba peut devenir :

[documents]
   path = /srv/samba/documents
   browseable = yes
   read only = yes
   valid users = @samba-docs-read @samba-docs-write
   write list = @samba-docs-write

La logique devient lisible immédiatement :

• groupe lecture : accès en lecture ;
• groupe écriture : accès en lecture/écriture.

Les permissions Unix doivent évidemment être configurées de manière cohérente avec cette politique.

L’exemple secret corrigé

Un partage non visible et réservé à un groupe peut ressembler à :

[secret]
   path = /srv/samba/secret
   browseable = no
   read only = yes
   valid users = @samba-secret
   write list = admin1
   read list = admin2

Dans cet exemple :

• seuls les membres du groupe Unix samba-secret peuvent entrer ;
• admin1 peut écrire ;
• admin2 reste explicitement en lecture seule ;
• le partage n’est pas présenté dans les listes classiques de partage.

admin1 et admin2 doivent évidemment également satisfaire la règle valid users, donc appartenir au groupe concerné.

Évitez root comme compte Samba ordinaire

L’ancien exemple utilisait :

write list = root,admin1

Ce n’est généralement pas une bonne architecture.

Le compte root dispose de privilèges extrêmement élevés sur le système Unix.

Il vaut mieux créer un groupe d’administrateurs du partage et accorder uniquement les droits nécessaires.

Par exemple :

write list = @samba-secret-admins

Le principe du moindre privilège possède un avantage appréciable :

quand un mot de passe fuit, la catastrophe est légèrement moins ambitieuse.

browseable = no ne sécurise pas un partage

Le paramètre :

browseable = no

empêche essentiellement le partage d’apparaître dans certaines opérations d’énumération.

Mais quelqu’un qui connaît son nom peut toujours essayer :

\\serveur\secret

Invisible n’est pas synonyme d’interdit.

La sécurité repose sur :

• l’authentification ;
• valid users ;
• les groupes ;
• les permissions Unix ;
• les ACL ;
• et la sécurité du réseau.

Masquer le nom est une mesure ergonomique.

Pas une fortification.

Les droits de création : create mask et directory mask

Samba permet de contrôler certains bits de permissions des nouveaux fichiers et répertoires.

Par exemple :

[documents]
   path = /srv/samba/documents
   read only = no
   valid users = @sambadocs
   create mask = 0660
   directory mask = 0770

Ici, les fichiers seront normalement limités à :

rw-rw----

et les répertoires à :

rwxrwx---

Ces paramètres sont utiles, mais ils interagissent avec :

• les permissions Unix ;
• les ACL ;
• les options du système de fichiers ;
• d’autres paramètres Samba.

Un masque n’est donc pas une permission indépendante tombée du ciel.

map to guest : à quoi servait l’exemple original ?

L’exemple initial contenait :

map to guest = Bad User

Ce paramètre est utile lorsqu’on veut réellement proposer des partages invités.

Avec :

map to guest = Bad User

un nom d’utilisateur inexistant peut être transformé en connexion invité.

En revanche, un utilisateur valide qui fournit simplement un mauvais mot de passe n’est pas censé être silencieusement transformé en invité avec ce réglage.

C’est une nuance importante.

Pour des partages authentifiés, inutile d’activer les invités

Si tous vos partages exigent une véritable authentification :

valid users = ...

vous pouvez très bien laisser le comportement invité désactivé.

Il n’est pas nécessaire d’ajouter :

map to guest = Bad User

simplement parce que la ligne existe dans un ancien tutoriel.

Les configurations de sécurité apprécient particulièrement les options dont on connaît la raison d’être.

Créer volontairement un partage invité

Si vous avez réellement besoin d’un partage accessible sans compte Samba, une configuration conceptuelle pourrait inclure :

[global]
   security = user
   map to guest = Bad User

[public]
   path = /srv/samba/public
   guest ok = yes
   read only = yes

Mais cela signifie bien :

« Je souhaite volontairement offrir un accès sans authentification traditionnelle à cette ressource. »

Ne faites pas cela sur des données sensibles.

Et sachez que certains Windows modernes restreignent fortement les connexions invité non sécurisées.

Ce n’est donc plus la méthode idéale pour éviter de créer trois comptes utilisateurs.

Tester smb.conf avant de toucher au service

Après chaque modification importante :

sudo testparm

Cette commande vérifie la cohérence interne du fichier de configuration.

Une sortie correcte se termine notamment par une validation de la configuration chargée.

Pour une sortie plus compacte :

sudo testparm -s

testparm vérifie la syntaxe et la cohérence Samba. Il ne prouve pas que vos permissions Unix, votre DNS et votre pare-feu sont corrects.

Mais éliminer une erreur de syntaxe avant de chercher un problème réseau constitue déjà une excellente manière de gagner vingt minutes.

Recharger Samba sans tout redémarrer

Après un :

sudo testparm

réussi, vous pouvez demander aux démons Samba de relire leur configuration :

sudo smbcontrol all reload-config

Les nouvelles connexions utiliseront la configuration actualisée.

Les connexions déjà ouvertes peuvent cependant conserver les paramètres de leur session existante.

Il peut donc être nécessaire de déconnecter puis reconnecter un client pour tester certaines modifications.

Et systemctl restart ?

Vous pouvez évidemment faire :

sudo systemctl restart smbd

et, si vous utilisez nmbd :

sudo systemctl restart nmbd

ou :

sudo systemctl restart smbd nmbd

Mais un redémarrage du serveur SMB interrompt les sessions existantes.

Sur une machine de test, ce n’est généralement pas dramatique.

Sur un serveur de fichiers utilisé par cinquante personnes travaillant dans le même tableur Excel, le résultat possède davantage de potentiel narratif.

Tester la liste des partages

Avec smbclient :

smbclient -L localhost -U alice

Le mot de passe est demandé interactivement.

Évitez de l’ajouter directement dans la commande.

Tester directement un partage

smbclient //localhost/documents -U alice

Une fois connecté, on dispose d’une interface rappelant un client FTP :

smb: \> ls
smb: \> get fichier.txt
smb: \> put test.txt
smb: \> quit

Pour Alice, le :

put test.txt

devrait fonctionner si les permissions Unix le permettent.

Pour Bob, notre configuration en lecture seule devrait le refuser.

Voilà un test légèrement plus convaincant que :

« Le dossier apparaît dans l’Explorateur, donc tout fonctionne. »

Tester depuis Windows

Depuis un poste Windows, saisissez :

\\nom-du-serveur\documents

ou avec son nom DNS complet :

\\fileserver.example.lan\documents

Un test direct par adresse IP peut également aider au diagnostic :

\\192.168.1.20\documents

Mais sur un réseau correctement administré, un nom DNS stable est généralement préférable.

Tester le port SMB depuis Windows

PowerShell permet :

Test-NetConnection fileserver.example.lan -Port 445

Si :

TcpTestSucceeded : False

il est inutile de commencer par modifier write list.

Le client n’atteint même pas encore le service SMB.

Quels ports utilise Samba ?

Pour le service SMB moderne, le port essentiel est :

TCP 445

Samba peut également écouter par défaut sur :

TCP 139

pour SMB transporté via NetBIOS.

Et nmbd utilise historiquement notamment les ports UDP :

137
138

Dans une architecture moderne sans dépendance NetBIOS, TCP 445 est la pièce centrale.

Le pare-feu : n’exposez pas SMB à la planète

Autorisez SMB uniquement depuis les réseaux qui en ont réellement besoin.

Un serveur interne pourrait par exemple être accessible depuis :

192.168.10.0/24

sans pour autant accepter TCP 445 depuis toutes les interfaces publiques.

N’exposez pas simplement TCP 445 directement à Internet.

Pour un accès distant, utilisez une architecture conçue pour cela :

• VPN ;
• tunnel sécurisé ;
• solution d’accès distant contrôlée ;
• ou autre mécanisme approprié à votre infrastructure.

Le monde extérieur dispose déjà de suffisamment de scanners automatiques sans que votre serveur de comptabilité leur fournisse une activité supplémentaire.

Vérifier les ports réellement ouverts

Sur Debian :

sudo ss -lntup

Pour rechercher notamment SMB :

sudo ss -lntup | grep -E ':(445|139|137|138)\b'

Vous pourrez ainsi distinguer :

« Le service est configuré. »

de :

« Un processus écoute réellement sur le port attendu. »

nmbd est-il vraiment nécessaire ?

Pour une infrastructure utilisant :

• DNS ;
• SMB2 ou SMB3 ;
• des chemins directs comme \\serveur\partage ;

nmbd n’est pas indispensable au transfert SMB lui-même.

Vous pouvez donc rencontrer des serveurs Samba parfaitement fonctionnels où le besoin principal est simplement :

smbd

Le vieux monde NetBIOS reste utile uniquement si votre environnement en dépend réellement.

Pourquoi le serveur n’apparaît-il pas dans « Réseau » sous Windows ?

Voici une confusion extrêmement fréquente :

« Mon serveur n’apparaît pas dans Réseau, donc Samba ne fonctionne pas. »

Pas nécessairement.

La découverte d’une machine et l’accès SMB à cette machine sont deux problèmes différents.

Essayez :

\\fileserver\documents

Si cela fonctionne, le serveur SMB fonctionne même s’il ne se présente pas spontanément dans la fenêtre « Réseau ».

Découverte Windows moderne avec WSD

Les Windows modernes utilisent notamment Web Services Discovery — WSD pour certaines fonctions de découverte réseau.

Debian propose par exemple :

sudo apt install wsdd2

Puis :

systemctl status wsdd2

wsdd2 peut annoncer le serveur aux clients Windows modernes.

Il ne remplace pas Samba.

Il aide simplement Windows à découvrir plus naturellement qu’un serveur de fichiers existe.

En résumé :

smbd sert les fichiers.
WSD aide Windows à découvrir la machine.
nmbd entretient les anciennes traditions NetBIOS.

Voir les connexions actives avec smbstatus

Une fois les utilisateurs connectés :

sudo smbstatus

Cette commande affiche notamment les connexions Samba en cours.

Pour ne voir que les partages :

sudo smbstatus -S

Pour les verrous :

sudo smbstatus -L

Pour un utilisateur :

sudo smbstatus -u alice

Très utile lorsqu’Alice assure qu’elle a fermé le fichier Excel et que Samba soutient une version juridiquement différente des événements.

Les verrous de fichiers

SMB gère des mécanismes de verrouillage permettant notamment aux applications d’éviter certaines écritures simultanées dangereuses.

C’est particulièrement important pour :

• les documents bureautiques ;
• certaines bases de données ;
• les applications multi-utilisateurs ;
• les fichiers modifiés simultanément.

Ne supprimez pas arbitrairement un verrou uniquement parce qu’un utilisateur veut ouvrir son document immédiatement.

Un verrou peut être le dernier élément empêchant deux personnes de transformer le même fichier en témoignage archéologique.

Consulter les journaux

Avec systemd :

journalctl -u smbd

Pour suivre en direct :

journalctl -u smbd -f

Et pour nmbd :

journalctl -u nmbd

Samba utilise également ses propres mécanismes de journalisation selon la configuration.

Augmenter temporairement le niveau de logs

Lors d’un diagnostic, on peut augmenter le niveau de journalisation.

Mais ne passez pas directement de :

log level = 1

à :

log level = 10

en production simplement parce que « plus de logs = plus d’informations ».

À des niveaux élevés, Samba est parfaitement capable de produire assez de détails pour transformer un diagnostic de cinq minutes en étude doctorale sur les paquets SMB.

Limiter Samba à certaines interfaces

Sur un serveur multi-interface, il peut être utile de limiter l’exposition du service.

On rencontre par exemple :

[global]
   interfaces = lo enp1s0
   bind interfaces only = yes

Ou avec un réseau :

interfaces = lo 192.168.10.0/24

Cette configuration peut réduire les interfaces sur lesquelles Samba fournit ses services.

Mais elle ne remplace pas un pare-feu.

Une option Samba est une politique applicative.

Le filtrage réseau doit rester un véritable filtrage réseau.

hosts allow et hosts deny

Samba possède également des mécanismes permettant de restreindre les clients selon leur adresse.

Par exemple :

hosts allow = 192.168.10. 127.
hosts deny = 0.0.0.0/0

Ce type de contrôle peut compléter la sécurité.

Mais là encore, ne remplacez pas une politique de pare-feu correctement conçue par quinze lignes dans smb.conf.

La défense en profondeur signifie plusieurs couches cohérentes.

Pas plusieurs couches dont personne ne sait laquelle bloque actuellement Bob.

Chiffrement SMB3

SMB3 permet de chiffrer les données transportées.

Pour un partage sensible, Samba peut exiger le chiffrement :

[confidentiel]
   path = /srv/samba/confidentiel
   valid users = @confidentiel
   read only = no
   server smb encrypt = required

Les clients incapables de négocier le niveau de chiffrement requis ne pourront pas utiliser le partage.

Cela peut être particulièrement intéressant lorsque le réseau sous-jacent ne doit pas être considéré comme entièrement digne de confiance.

Chiffrement SMB et chiffrement du disque ne sont pas la même chose

Le chiffrement SMB protège les données pendant leur transport entre client et serveur.

Il ne chiffre pas automatiquement :

/srv/samba/confidentiel

sur le disque physique.

Pour les données au repos, il faut envisager des mécanismes comme :

• LUKS ;
• chiffrement du stockage ;
• fonctionnalités du système de fichiers ;
• ou une solution adaptée à votre architecture.

Une serrure sur le camion ne remplace pas la serrure de l’entrepôt.

Le partage [homes]

Samba possède une section spéciale :

[homes]

Elle permet de publier dynamiquement le répertoire personnel d’un utilisateur authentifié.

Une configuration peut ressembler conceptuellement à :

[homes]
   browseable = no
   read only = no

Lorsqu’Alice se connecte, Samba peut lui présenter son propre répertoire personnel.

Cette fonctionnalité est pratique dans certains environnements.

Elle doit néanmoins être configurée consciemment : publier automatiquement les homes de tous les utilisateurs n’est pas forcément ce que vous souhaitez sur chaque serveur.

Accès basé sur les groupes : la vraie méthode scalable

Pour quelques utilisateurs :

valid users = alice bob charles

fonctionne.

Pour une entreprise, préférez :

valid users = @finance

ou des groupes dédiés :

valid users = @samba-finance-read @samba-finance-write
write list = @samba-finance-write

Puis gérez l’appartenance avec les outils Unix ou votre annuaire.

La configuration du partage décrit alors les rôles, pas la liste des employés présents lors de sa création en 2022.

Un serveur membre Active Directory : autre niveau

Dans une entreprise possédant Active Directory, il peut être préférable que Samba utilise directement les comptes du domaine plutôt que de recréer :

alice
bob
charles

localement sur chaque serveur.

On entre alors dans une configuration avec notamment :

• server role = member server ;
• Kerberos ;
• DNS ;
• jonction au domaine ;
• Winbind ;
• mapping SID ↔ UID/GID.

Ce n’est pas une extension de trois lignes à notre exemple autonome.

C’est une architecture distincte qui mérite son propre article.

Quelques mauvaises idées fréquentes

Mettre chmod 777 parce que « Samba refuse d’écrire »

chmod -R 777 /srv/samba

fait souvent disparaître le problème.

Il fait également disparaître une partie significative de votre politique de permissions.

Un diagnostic préférable consiste à examiner :

namei -l /srv/samba/documents
ls -ld /srv/samba/documents
getfacl /srv/samba/documents
id alice

Puis à corriger précisément la permission qui pose problème.

Utiliser root pour tout

Si chaque partage possède :

valid users = root

vous n’avez pas créé une politique de sécurité.

Vous avez créé un raccourci pour l’incident futur.

Réactiver SMB1 pour un vieux copieur

Traitez le périphérique hérité comme le problème spécifique qu’il est.

Ne rétrogradez pas toute l’infrastructure pour lui éviter une retraite méritée.

Mettre un partage en browseable = no et le considérer comme secret

Le nom peut être masqué.

Les permissions doivent toujours faire le vrai travail.

Exposer TCP 445 sur Internet

Non.

Votre serveur de fichiers interne n’a pas besoin de recevoir les salutations enthousiastes de tous les scanners automatisés de la planète.

Modifier smb.conf puis redémarrer immédiatement

Faites d’abord :

sudo testparm

Le redémarrage n’est pas un parseur de configuration.

C’est simplement une manière plus spectaculaire de découvrir qu’il manquait un crochet.

Diagnostiquer un partage inaccessible

Un utilisateur annonce :

« Le partage ne marche pas. »

Cette phrase contient à peu près quatre pour cent des informations nécessaires.

1. Le service fonctionne-t-il ?

systemctl status smbd

2. La configuration est-elle valide ?

sudo testparm -s

3. Le partage est-il déclaré ?

smbclient -L localhost -U alice

4. Le chemin Unix existe-t-il ?

ls -ld /srv/samba/documents

5. L’utilisateur Unix existe-t-il ?

id alice

6. Le compte Samba existe-t-il ?

sudo pdbedit -L | grep alice

7. Peut-il entrer dans tous les répertoires parents ?

namei -l /srv/samba/documents

Un répertoire final peut parfaitement être en 770 tout en restant inaccessible parce qu’un parent interdit sa traversée.

8. Quelles sont les ACL ?

getfacl /srv/samba/documents

9. Samba écoute-t-il ?

sudo ss -lntp | grep ':445'

10. Le client atteint-il le serveur ?

Depuis Windows :

Test-NetConnection fileserver -Port 445

11. Que disent les logs ?

journalctl -u smbd -n 100

12. Existe-t-il déjà une connexion avec une autre identité ?

Sur Windows :

net use

Une ancienne connexion SMB utilisant un autre compte peut empêcher une nouvelle authentification au même serveur.

Le problème n’est alors pas Samba.

Windows se souvient simplement d’une relation précédente et refuse de tourner la page.

Le partage fonctionne en local mais pas depuis Windows

Si ceci fonctionne :

smbclient //localhost/documents -U alice

mais pas :

\\fileserver\documents

depuis un poste distant, concentrez l’enquête sur :

• la résolution DNS ;
• le routage ;
• le pare-feu ;
• TCP 445 ;
• les interfaces sur lesquelles Samba écoute ;
• les restrictions réseau.

Ne modifiez pas quinze permissions Unix lorsque le paquet réseau n’arrive même pas à la machine.

Le partage s’ouvre mais l’écriture échoue

Vérifiez deux niveaux.

Niveau Samba

valid users
read only
write list
read list

Niveau Unix

id alice
ls -ld /srv/samba/documents
getfacl /srv/samba/documents

C’est généralement là que l’on découvre que :

write list = alice

était parfait, mais que le répertoire appartenait à :

root:root

avec :

755

Samba avait donné son accord.

Linux avait déjà appelé la sécurité.

Le partage fonctionne par IP mais pas par nom

Si :

\\192.168.1.20\documents

fonctionne, mais :

\\fileserver\documents

échoue, examinez la résolution de noms.

Depuis Windows :

Resolve-DnsName fileserver

ou :

nslookup fileserver

Depuis Linux :

getent hosts fileserver

Le DNS est régulièrement accusé de tous les problèmes réseau.

Cette fois, il pourrait effectivement être coupable.

Le serveur fonctionne mais n’apparaît pas dans Réseau

Encore une fois :

\\fileserver\documents

peut parfaitement fonctionner alors que la découverte graphique ne montre rien.

Examinez alors :

• WSD ;
• wsdd2 ;
• le profil réseau Windows ;
• les règles pare-feu de découverte ;
• les mécanismes de résolution du réseau.

Ne réactivez pas SMB1 pour récupérer un joli ordinateur dans la rubrique « Réseau ».

C’est un prix de décoration intérieure légèrement excessif.

Configuration complète raisonnable

Pour un petit serveur autonome, une base peut ressembler à ceci :

[global]
   workgroup = WORKGROUP
   server role = standalone
   security = user

[documents]
   path = /srv/samba/documents
   browseable = yes
   read only = yes
   valid users = @samba-docs-read @samba-docs-write
   write list = @samba-docs-write
   create mask = 0660
   directory mask = 0770

[secret]
   path = /srv/samba/secret
   browseable = no
   read only = no
   valid users = @samba-secret
   server smb encrypt = required

Cette configuration est volontairement lisible.

Elle ne tente pas d’insérer cinquante paramètres de performance copiés depuis un forum de 2011.

Ne « tunez » pas Samba au hasard

Les anciens tutoriels contiennent parfois de longues séries de paramètres comme :

socket options = ...
read raw = yes
write raw = yes
max xmit = ...

Beaucoup correspondaient à des systèmes, noyaux et réseaux très différents de ceux d’aujourd’hui.

Les systèmes modernes possèdent déjà de nombreux mécanismes d’optimisation.

Ne modifiez donc pas un paramètre bas niveau uniquement parce que son nom contient :

TCP_NODELAY

et semble manifestement avoir été inventé pour rendre Internet plus rapide.

Une procédure complète de mise en service

1. Installer Samba

sudo apt update
sudo apt install samba smbclient

2. Sauvegarder la configuration

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

3. Créer les utilisateurs

sudo useradd -M -s /usr/sbin/nologin alice
sudo useradd -M -s /usr/sbin/nologin bob

4. Créer le groupe

sudo groupadd sambadocs
sudo usermod -aG sambadocs alice
sudo usermod -aG sambadocs bob

5. Créer le répertoire

sudo mkdir -p /srv/samba/documents
sudo chown root:sambadocs /srv/samba/documents
sudo chmod 2770 /srv/samba/documents

6. Ajouter les comptes Samba

sudo smbpasswd -a alice
sudo smbpasswd -a bob

7. Ajouter le partage

[documents]
   path = /srv/samba/documents
   browseable = yes
   read only = yes
   valid users = alice bob
   write list = alice

8. Valider smb.conf

sudo testparm

9. Recharger la configuration

sudo smbcontrol all reload-config

10. Tester localement

smbclient -L localhost -U alice
smbclient //localhost/documents -U alice

11. Vérifier le port

sudo ss -lntp | grep ':445'

12. Tester depuis Windows

\\fileserver\documents

13. Vérifier les connexions

sudo smbstatus

À ce stade, vous avez déjà effectué davantage de vérifications que beaucoup de procédures ayant commencé par :

« On va essayer de redémarrer le serveur pour voir. »

Les commandes indispensables

Commande	Utilité
apt install samba	Installer le serveur Samba
smbpasswd -a utilisateur	Ajouter ou définir le mot de passe d’un compte Samba
smbpasswd -d utilisateur	Désactiver un compte Samba
smbpasswd -e utilisateur	Réactiver un compte Samba
smbpasswd -x utilisateur	Supprimer un compte Samba
pdbedit -L	Lister les comptes Samba locaux
testparm	Vérifier la configuration Samba
smbcontrol all reload-config	Demander aux démons de relire smb.conf
smbclient -L serveur	Lister les partages proposés
smbclient //serveur/partage	Tester directement un partage
smbstatus	Voir les connexions et verrous actifs
journalctl -u smbd	Consulter les journaux du serveur SMB
ss -lntp	Examiner les ports TCP en écoute

Les paramètres smb.conf à retenir

Paramètre	Rôle
path	Répertoire Unix réellement partagé
browseable	Indique si le partage apparaît dans les listes de navigation
valid users	Définit qui peut accéder au partage
read only	Définit si l’écriture est normalement interdite
write list	Accorde l’écriture à certains comptes ou groupes
read list	Force certains comptes ou groupes en lecture seule
guest ok	Autorise l’accès invité lorsqu’il est correctement configuré
create mask	Contrôle certains droits Unix des nouveaux fichiers
directory mask	Contrôle certains droits Unix des nouveaux répertoires
server smb encrypt	Contrôle ou impose le chiffrement SMB selon la configuration

Bonnes pratiques

• Utilisez SMB2/SMB3 et laissez SMB1 désactivé sauf nécessité réellement documentée.
• Utilisez des groupes plutôt que des listes interminables d’utilisateurs.
• Ne confondez jamais permissions Samba et permissions Unix.
• Évitez les comptes root pour les accès quotidiens aux partages.
• Utilisez testparm avant chaque rechargement important.
• N’exposez pas TCP 445 directement à Internet.
• Utilisez un pare-feu pour limiter les réseaux autorisés.
• Ne considérez pas browseable = no comme une mesure de sécurité.
• Consultez smbstatus avant d’interrompre un serveur utilisé.
• Utilisez le chiffrement SMB3 lorsque la confidentialité du trafic le justifie.
• Ne modifiez pas vingt paramètres de performance dont vous ne connaissez pas précisément l’effet.
• Gardez une sauvegarde de smb.conf qui fonctionnait.

Résumé : du disque Linux au dossier Windows

Lorsqu’Alice ouvre :

\\fileserver\documents

voici, de manière simplifiée, ce qui se produit :

1. le poste client trouve l’adresse du serveur ;
2. il contacte le service SMB, généralement sur TCP 445 ;
3. client et serveur négocient une version SMB compatible ;
4. Samba authentifie Alice ;
5. le compte SMB est associé à une identité Unix ;
6. Samba vérifie que le partage autorise Alice ;
7. Linux vérifie que cette identité possède les droits nécessaires sur les fichiers ;
8. le contenu de /srv/samba/documents est exposé au client ;
9. les lectures, écritures et verrous sont traduits entre les deux mondes.

Pour Alice :

\\fileserver\documents\rapport.xlsx

Pour Debian :

/srv/samba/documents/rapport.xlsx

Entre les deux :

SMB, authentification, UID, GID, ACL, verrouillage, protocoles réseau et une quantité respectable de code dont l’unique objectif est de faire croire à deux systèmes d’exploitation très différents qu’ils se sont toujours parfaitement entendus.

Conclusion : Samba n’est pas mystérieux, il possède simplement plusieurs couches

Samba acquiert rapidement une réputation de configuration ésotérique parce qu’un problème visible dans Windows peut en réalité provenir :

• du compte Samba ;
• du compte Unix ;
• du groupe ;
• des permissions POSIX ;
• des ACL ;
• de smb.conf ;
• du DNS ;
• du pare-feu ;
• de la découverte réseau ;
• ou d’une ancienne session SMB déjà ouverte côté Windows.

Mais une fois ces couches séparées mentalement, le fonctionnement devient beaucoup plus logique.

Pour un serveur autonome simple :

1. créez les identités Unix ;
2. créez les comptes Samba ;
3. configurez les permissions du système de fichiers ;
4. déclarez le partage dans smb.conf ;
5. vérifiez avec testparm ;
6. testez avec smbclient ;
7. ouvrez uniquement les accès réseau nécessaires.

Samba est un outil extrêmement puissant.

Il peut transformer un Debian parfaitement ordinaire en serveur de fichiers utilisable naturellement par Windows, Linux et de nombreux autres systèmes.

Il demande simplement que vous lui expliquiez précisément :

qui peut entrer, où se trouvent les fichiers et ce que chaque personne a le droit d’en faire.

Une exigence finalement assez raisonnable.

La véritable crise de nerfs commence généralement lorsqu’on répond :

« Tout le monde devrait avoir les droits. J’ai mis chmod 777. »

À cet instant, Samba n’est plus le problème.

Il est simplement le témoin.