Manuel pratique Comp’Assist · Révision : 2 octobre 2026. Exemples pédagogiques, à adapter. Les fonctions visibles dépendent de la version, des droits et des paquets installés.
Vérifier que le chemin de données est un volume monté sur le bon stockage et qu’il sera présent avant le démarrage du service. Identifier utilisateurs et groupes Linux, puis le mécanisme d’authentification Samba. Un compte Samba local et un compte d’annuaire ne se gèrent pas de façon identique. Dans un CT non privilégié, examiner le mapping d’UID avant modification des propriétaires.
| Paramètre | Effet | Choix raisonné |
|---|---|---|
[documents] |
Nom du partage | Nom stable et compréhensible |
path |
Chemin serveur | Volume de données réellement monté |
browseable |
Visibilité dans la liste | Cacher n’est pas interdire l’accès |
read only |
Politique d’écriture Samba | Lecture seule pour une source ISO commune |
valid users |
Comptes/groupes autorisés | Liste explicite selon rôle |
guest ok |
Accès invité | Refuser pour les données privées |
create mask / directory mask |
Limitation des droits créés | Cohérent avec groupes et ACL |
| ACL et héritage | Droits fins du système de fichiers | Tester depuis les clients réels |
Les droits du partage ne dépassent pas magiquement ceux du système de fichiers. Une autorisation Samba peut donc encore rencontrer un refus Linux. Inversement, des droits Linux larges et un partage mal limité peuvent exposer davantage que prévu.
Fragment de partage à adapter après création du groupe et du dossier avec droits appropriés :
[documents]
path = /srv/documents
browseable = yes
read only = no
guest ok = no
valid users = @documents
Ce fragment ne crée ni groupe, ni utilisateurs, ni permissions Linux. Il ne doit pas remplacer toute la section globale du serveur. Vérifier la configuration avec testparm avant un rechargement supporté, puis tester une nouvelle connexion. Les sessions déjà ouvertes peuvent conserver certains paramètres.
Ouvrir \\serveur-exemple\documents avec un compte autorisé. Si nécessaire, utiliser le Gestionnaire d’identification pour examiner l’identité enregistrée, sans effacer toutes les informations d’autres applications. Windows peut réutiliser une connexion SMB existante avec une autre identité ; fermer les fichiers et sessions concernés avant un nouveau test.
Ne pas réactiver SMB1 pour contourner un problème avec un ancien appareil sans évaluation spécifique. Ne pas publier SMB directement sur Internet ; passer par un VPN. La signature et le chiffrement se configurent selon versions clients et exigences, puis se vérifient sur la connexion négociée.
Avec un compte autorisé : lire, créer, renommer, modifier et supprimer un fichier de test, selon les droits prévus. Avec un compte limité : vérifier le refus d’écriture ou d’accès. Tester un nouveau fichier créé depuis deux systèmes, son groupe et ses ACL. Éviter un chmod récursif sur un arbre de production : cela peut détruire les différences de droits métier.
Inclure données, ACL/attributs utiles, configuration Samba et mécanismes de comptes appropriés dans une sauvegarde protégée. Restaurer un dossier de test avec ses permissions et vérifier l’accès. Surveiller capacité, fichiers ouverts et logs ; une copie des fichiers sans les droits peut produire une restauration techniquement complète mais trop ouverte. Planifier les interventions qui nécessitent une déconnexion des utilisateurs.