J’ai passé trois jours à déboguer la réplication d’un partage Samba sur un serveur CMSimple_XH chez un éditeur juridique à Rennes — enfin, pas exactement CMSimple_XH cette fois, mais l’infrastructure qui l’hébergeait. Leur configuration était surdimensionnée, leurs permissions sous-optimisées. Voilà ce que j’en ai retenu, pour ceux qui doivent faire cohabiter Windows et Linux via CIFS/Samba dans une petite structure.
Pourquoi CIFS/Samba reste pertinent
CIFS (Common Internet File System) est le protocole de partage de fichiers de Windows ; Samba est l’implémentation qui permet à un serveur Linux de parler ce protocole nativement. Pour une PME avec des postes Windows et un serveur Linux (souvent moins cher à licencier et plus simple à maintenir sur le long terme), Samba reste la solution la plus directe pour du partage de fichiers fiable, sans dépendre d’un cloud tiers.
Installation et configuration de base
Sur Debian ou Ubuntu Server :
sudo apt install samba
sudo nano /etc/samba/smb.confUn partage minimal fonctionnel :
[partage_pme]
path = /srv/partage
browsable = yes
writable = yes
guest ok = no
valid users = @equipe
create mask = 0660
directory mask = 0770Après modification, redémarrage du service et création de l’utilisateur Samba (distinct du mot de passe système) :
sudo systemctl restart smbd
sudo smbpasswd -a nom_utilisateurLe piège rencontré : permissions Unix vs ACL Samba
Une PME de Rennes m’a signalé que certains utilisateurs pouvaient lire mais pas écrire dans un dossier partagé, malgré des droits Samba apparemment corrects. Le problème venait de la superposition de deux couches de permissions : les droits Unix classiques (chmod, chown) et le masque de création défini dans smb.conf. Un fichier créé avec un create mask trop restrictif reste inaccessible en écriture même si l’utilisateur Samba a théoriquement le droit d’écrire, parce que le système de fichiers sous-jacent applique ses propres règles en plus.
La commande qui m’a permis de diagnostiquer précisément :
getfacl /srv/partage
namei -l /srv/partage/dossier/fichier.docxnamei -l décompose chaque segment du chemin avec ses permissions — souvent la cause réelle est un dossier parent mal configuré, pas le fichier final qu’on inspecte en premier réflexe.
Performances sous charge
Sur un partage avec une vingtaine de postes actifs simultanément, le paramètre socket options a un impact mesurable. La valeur par défaut convient rarement à un réseau local moderne :
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072Sur le cas cité plus haut, ce réglage a réduit le temps d’ouverture de fichiers volumineux (documents juridiques avec pièces jointes) d’environ 40 %, mesuré sur une dizaine d’ouvertures répétées avant et après changement — pas une moyenne théorique, une mesure directe sur leur matériel.
Ce que je ne recommande pas
Attention, beaucoup se trompent en ouvrant un partage SMBv1 pour la « compatibilité » avec de vieux postes. SMBv1 est obsolète et vulnérable (c’est le protocole exploité par WannaCry en 2017) ; la bonne réponse à un poste incompatible n’est pas de rouvrir SMBv1 côté serveur, mais de mettre à jour ou isoler ce poste.
Sauvegarde et cohérence des permissions dans le temps
Un point que je vérifie systématiquement lors d’un audit : les permissions Samba définies dans smb.conf ne survivent pas nécessairement à une restauration de sauvegarde si l’outil de sauvegarde ne préserve pas les attributs étendus du système de fichiers. J’ai vu un cas où une restauration après incident matériel avait remis tous les fichiers avec les permissions par défaut de l’utilisateur root, cassant l’accès en écriture pour l’ensemble de l’équipe sans qu’aucune erreur ne remonte au niveau de l’outil de sauvegarde lui-même — seulement au niveau des utilisateurs, plusieurs heures après la restauration.
La bonne pratique consiste à tester une restauration complète au moins une fois avant d’en avoir besoin en urgence, et à vérifier explicitement les permissions du résultat, pas seulement la présence des fichiers.
Intégration avec un contrôleur de domaine
Pour une structure au-delà d’une dizaine de postes, l’authentification Samba autonome (via smbpasswd) montre vite ses limites : chaque utilisateur doit être créé manuellement sur le serveur de fichiers, séparément de tout autre système d’authentification. Intégrer Samba à un contrôleur de domaine existant (Active Directory ou Samba AD) centralise la gestion des comptes et évite la dérive progressive entre les utilisateurs Samba et les utilisateurs réels de l’organisation — une dérive que j’ai régulièrement constatée sur des configurations vieillissantes, avec des comptes Samba actifs pour des personnes ayant quitté la structure depuis longtemps.
À retenir pour votre projet
Documentez le masque de permissions dès la mise en place, testez avec namei -l avant de chercher plus loin, et surveillez le protocole minimum accepté. C’est un choix à faire selon votre contexte, pas une vérité universelle — mais SMBv1 n’en fait partie sous aucun contexte en 2025.
Chiffrement du partage : SMB3 et signature obligatoire
Depuis SMB3, le protocole supporte le chiffrement natif des échanges, une option que je recommande d’activer pour tout partage transitant sur un réseau qui n’est pas strictement isolé (VLAN dédié sans autre trafic) :
[global]
server min protocol = SMB3
smb encrypt = requiredCe réglage a un coût en performance, généralement mineur sur du matériel récent, mais représente une protection significative si un poste compromis venait à écouter le trafic réseau local — un scénario qui reste rare en PME mais pas négligeable, en particulier sur des réseaux où le Wi-Fi invité et le réseau professionnel ne sont pas correctement séparés, une configuration que je retrouve encore régulièrement lors d’un premier audit.
Montage côté client Linux
Pour les structures avec un mélange de postes Linux et Windows, le montage d’un partage Samba côté Linux mérite sa propre attention. Un montage via /etc/fstab mal configuré peut bloquer le démarrage complet du poste si le partage réseau n’est pas disponible au moment du montage :
//serveur/partage_pme /mnt/partage cifs credentials=/etc/samba/creds,uid=1000,gid=1000,_netdev 0 0L’option _netdev indique au système d’attendre que le réseau soit disponible avant de tenter le montage, et évite les blocages au démarrage que j’ai vus sur des postes Linux configurés sans cette option — un détail simple, mais qui a bloqué le démarrage complet d’un poste pendant plusieurs minutes avant que la cause ne soit identifiée.
Pour aller plus loin
Pour une référence externe, consultez le site officiel de Samba ainsi que sa documentation.