[Debian 10 + Samba] Problèmes de correspondances de droits sur fichiers et répertoires

Support Debian
#1

Bonjour à tous,

J’ai un soucis avec l’utilisation de SAMBA.

Je veux partager sur le serveur le répertoire « /test » :

total 28K
drwxrws---  4 user_A common 4,0K juin  10 19:10 .
drwxrws--- 16 nobody          common 4,0K mars  24 18:28 ..
drwxrws---  2 user_A common 4,0K juin  10 19:07 Dossier_A
drwxrws---  2 user_B  common 4,0K juin  10 19:08 Dossier_B
-rw-rw----  1 user_A common    6 juin  10 19:09 fichier_A
-rw-rw----  1 user_B  common    6 juin  10 19:09 fichier_B

L’utilisateur user_A (uid=1000, gid=1000) et l’utilisateur user_B (uid=1001, gid=1001) appartiennent tous deux au groupe common (gid=1002) sur le serveur.

Mais un utilisateur bob (uid=1001, gid=1001) sur le poste client devant se connecter en tant que user_A sur le serveur SAMBA voit le répertoire comme ceci :

drwxr-xr-x 2 user_A common   0 juin  10 19:10 .
drwxr-xr-x 2 user_A common   0 mars  24 18:28 ..
drwxr-xr-x 2 user_A common   0 juin  10 19:07 Dossier_A
drwxr-xr-x 2 user_A common   0 juin  10 19:08 Dossier_B
-rwxr-xr-x 1 user_A common   6 juin  10 19:09 fichier_A
-rwxr-xr-x 1 user_A common   6 juin  10 19:09 fichier_B

Tous les fichiers et répertoires appartiennent à l’utilisateur user_A, ce qui n’est pas vrai et les droits d’accès ne sont pas les bons.
De plus, bob n’a pas le droit de créer de répertoires ou de nouveaux fichiers sur le serveur comme si il n’était pas reconnu en tant que user_A.

Alors que sur un poste Windows 10, l’utilisatrice alice se connecte sans problème sur le serveur en tant que user_A et peut créer à loisir de nouveaux répertoires et nouveaux fichiers.

Le problème est donc entre un client sous debian 10 buster et un serveur sous debian 10 buster.

La configuration du serveur est (/etc/samba/smb.conf) :

[global]
   workgroup = MON_WORKGROUP
   server string = %h server
   dns proxy = no
   log file = /var/log/samba/log.%m
   log level = 1
 
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
[homes]
   comment = Répertoires utilisateurs
   browseable = no
    writable = yes
   create mask = 0775
   directory mask = 0775
   valid users = %S
[TEST]
   comment = Partage TEST
   path = /test
   browseable = yes
   valid users = user_A user_B
   writable = yes

et le fichier /etc/fstab sur le client contient la ligne :

//MON_SERVEUR/test                           /test         cifs   noauto,user,uid=1000,forceuid,gid=1002,forcegid,credentials=/root/smb.credentials      0 0

avec dans le fichier /root/smb.credentials les identifiants qui vont bien pour l’utilisateur user_A.

Savez-vous ce qui ne va pas ?
Merci de votre aide.

#2

Bob a le meme uid et gid que user_B. mauvaise idée.

#3

Bonjour Zargos,
Je sais, mais je n’ai pas le choix, sur le poste client l’uid 1000 est déjà pris par un autre utilisateur qui est synchronisé avec un serveur NFS. Et pour le coup, les uid et gid doivent être strictement identiques.

Idéalement, j’aurais préféré connecter l’utilisateur bob directement en NFS sur le serveur du compte user_A, mais les uid et gid étant différents, ce n’est pas possible.
Je me suis donc tourné vers SAMBA qui normalement doit pouvoir gérer cette différence…

#4

Le problème ne vient pas du serveur.
Il fonctionne très bien avec les postes Windows.

Et sur le poste client de bob une connexion établie directement depuis le gestionnaire de fichiers dophin de KDE sans passer par les paramétrages de /etc/fstab fonctionne bien. Même si les champs « propriétaire » et « groupe d’utilisateurs » affichés par dolphin restent vides, bob peut enfin créer des fichiers et des répertoires. Une vérification sur le serveur montre que les fichiers et répertoires créés ont les bons droits d’accès (-rw-rw----). Mais le montage n’est pas permanent et il faut le recréer à chaque fois…

#5

Finalement, il est possible de créer un lien permanent dans dolphin en passant par « Ajouter un dossier réseau » dans la section « Réseau ».

J’ai donc contourné le problème initial, mais ça ne l’a pas résolu.
Qu’est-ce qui ne fonctionne pas dans le fichier /etc/fstab ???

#6

Alors choisi un début de plage uid/gid qui n’est pas utilisé ailleurs: 5000 par exemple. Comme ça pas de problèmes.

Tu fige l’uid et le gid, je ne pense pas que ce soit une bonne idée.

#7

Autre point, j’utiliserais plutôt la validation de groupe, tel que :
valid users = @common dans votre cas :stuck_out_tongue:
Voire à utiliser aussi l’option write list paramétrée aussi sur le groupe, au besoin.

Bien vérifier que les utilisateurs font partie du groupe :
getent group common

#8

Dis, comment est-ce que bob accède au répertoire pour avoir ce retour ?

#9

Bonjour Almtesh,
le répertoire distant NFS étant monté sur /test, l’utilisateur bob y accède depuis une console par :

$ cd /test
$ ls -lah
#10

Ah, mais si le montage est en NFS, ce n’est pas samba le problème.
C’est particulier de monter dans un répertoire /test, j’aurais plutôt utilisé /mnt/test, mais peu importe.
Tu peux nous donner le retour de la commande suivante :

mount | grep /test

Merci.

#11

Mince, c’est un coquille de ma part. J’ai l’habitude d’utiliser NFS, mais ici il s’agit bien de SAMBA.

Voici la sortie de :

$ mount | grep /test
//MON_SERVEUR/test on /test type cifs (rw,nosuid,nodev,relatime,vers=3.1.1,cache=strict,username=user_A,domain=MON_WORKGROUP,uid=1000,forceuid,gid=1002,forcegid,addr=10.0.0.128,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=bob)
#12

il est possible que Bob n’ai pas accès à la racine. Car normalement un utilisateur standard n’a pas accès à la racine justement.

#13

Merci Zargos.
Je viens d’essayer de monter le répertoire dans /mnt/test en donnant tous les droits d’accès à /mnt et /mnt/test (drwxrwxrwx).

Lors du montage de la partition SAMBA, j’obtiens exactement la même sortie que précédemment :

drwxr-xr-x 2 user_A common   0 juin  10 19:10 .
drwxr-xr-x 2 user_A common   0 mars  24 18:28 ..
drwxr-xr-x 2 user_A common   0 juin  10 19:07 Dossier_A
drwxr-xr-x 2 user_A common   0 juin  10 19:08 Dossier_B
-rwxr-xr-x 1 user_A common   6 juin  10 19:09 fichier_A
-rwxr-xr-x 1 user_A common   6 juin  10 19:09 fichier_B
#14

Probablement que ces options outrepassent les appartenances envoyées par le serveur.
On peut le vérifier assez rapidement en regardant les retours des commandes suivantes :

  • getent passwd 1000
  • getent group 1002