Mount cifs et permissions

Support Debian
#1

Bonjour,

après une mise en place d’un serveur debian ltsp (+kerberos et winbind pour la liaison avec Active Directory), j’ai un problème de session. Après une petite recherche je me suis rendu compte d’un problème avec mount.

Si je fais simlpement en root :

le montage est ok, mais le mask n’est appliqué qu’aux sous-dossiers de dupont et pas à dupont directement.

ll /home/WIN2K/ total 0 dr-xr-x--x 1 dupont utilisa._du_domaine 0 jun 10 11:10 dupont
par contre mon masque (dir_mode) s’applique bien aux sous-dossiers :

ll /home/WIN2K3/dupont/ total 0 drwxr-x--x 1 dupont utilisa._du_domaine 0 jun 9 08:33 Bureau drwxr-x--x 1 dupont utilisa._du_domaine 0 jun 5 16:28 System drwxr-x--x 1 dupont utilisa._du_domaine 0 oct 12 2007 web

Le problème de pas avoir de droit d’écriture sur dupont fait que la session gnome se lance pas (bah oui les fichiers de config .gnome… ne peuvent pas se créer).

Une solution ? Est-ce un bug ? Quelqu’un a déjà eu ce problème ?
merci.

#2

je pense que c’est parce que /home/WIN2K3/dupont est un dossier local qu’il n’est pas concerné par le masque de la commande mount.

#3

Il n’y a vraiment pas moyen de changer les droits sur ce dossier de montage alors ?

Autre chose, je viens de m’aperçevoir que dans les droits ntfs sur le dossier dupont, il y a :

  • “afficher le dossier” pour l’utilisateur dupont
  • le restes des accès pour dupont est situé dans “autorisations spéciales”.

J’ai installé les acl, mais quand je monte avec l’option acl toujours pareil…

#4

j’avais un client sous ubuntu qui trainait. J’ai donc fait aussi un test avec :

  • intégration au domaine
  • même fichier de conf

…et quand je lance la même commande, lui au moins m’applique bien mon masque sur le point de montage (donc dupont/ accessible en écriture).

Bug debian ?

#5

un petit up!

sachant que j’ai l’origine du problème. Ca a avoir le kernel :

  • 2.6.24 : ok
  • 2.6.26-1, 2.6.26-2 : le masque n’est pas appliqué au point de montage

quelqu’un pourrait confirmer ?

#6

j’ai trouvé l’erreur et comme j’ai posté mon problème un peu partout je recopie-colle la réponse :

En activant le mode debug de mount.cifs (echo 3 > /proc/fs/cifs/cifsFYI), des erreurs s’affichent dans la sortie dmesg :

# dmesg [ 7845.389949] fs/cifs/xattr.c: CIFS VFS: in cifs_getxattr as Xid: 50 with uid: 0 [ 7845.389953] fs/cifs/xattr.c: illegal xattr request security.selinux (only user namespace supported) [ 7845.389956] fs/cifs/xattr.c: CIFS VFS: leaving cifs_getxattr (xid = 50) rc = -95 [ 7845.389964] fs/cifs/xattr.c: CIFS VFS: in cifs_getxattr as Xid: 51 with uid: 0 [ 7845.389967] fs/cifs/xattr.c: CIFS VFS: leaving cifs_getxattr (xid = 51) rc = -95

donc en utilisant l’option nouser_xattr ça règle le problème :

mount -t cifs //192.168.224.1/MYSHARE$ TEST -o username=admin,uid=10066,gid=10000,dir_mode=0755,nouser_xattr --verbose

ll . drwxr-xr-x 1 admin utilisa._du_domaine 0 jun 11 17:14 TEST

#7

tant mieux

personnellement les montages cifs je les fait via pam-mount et il fait tout bien tout seul lors du login des utilisateurs. regardes par là si ça peut te simplifier certaines tâches d’administration.

mais au moins maintenant, tu sais faire… :smt006

#8

justement, j’utilise pam_mount. La finalité est un montage automatique des répertoires perso windows dans le /home/DOMAINE sur mon serveur LTSP.

mais dans le /etc/security/pam_mount.conf.xml, je coinçais pareil :

<cifsmount>mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)"</cifsmount>

donc la, le fait que ça réussisse manuellement, pam_mount n’échouera pas lors de la connexion de l’utilisateur sur LTSP.

je mettrais ça dans mon point de montage

<volume user="*" fstype="cifs" server="192.168.224.1" path="%(USER)$" mountpoint="~" options="dir_mode=0755,nouser_xattr" />

#9

ce qui est étrange c’est que pam_mount se charge de la création du point d emontage si il n’existe pas et gère bien les droits dessus.

#10

arf, je me suis fais une fausse joie. nouser_xattr n’a rien changé. J’étais encore sur un partage qui lui marche bien.

Je bloque donc toujours les partages des répertoires utilisateurs mais pas les autres partages. Donc toujours un soucis avec ce foutu kernel 2.6.26 !!

#11

suite et fin !

Après une discussion sur la liste du client-cifs, l’origine du problème venait de l’attribut lecteur seule, ATTR_READONLY.

Il s’avère qu’il y a une erreur d’interprétation depuis 2.6.26 (on va dire comme ça) :

  • pour windows, lecture seule est simplement utilisé pour forcer l’explorateur à lire le fichier Desktop.ini, donc tous les programmes windows n’y font pas attention. Ni même moi d’ailleurs, trouvez-vous pas bizarre qu’un répertoire en lecture seule soit modifiable ?? Bref donc sous windows on a un droit d’écriture.
  • pour cifs, ben si ya l’attribut lecteur seule alors r-xr-xr-x donc comportement normal (on va dire comme ça aussi :wink:

Du coup en modifiant la base de registre de mon serveur windows pour qu’il n’utilise plus l’attribut lecture seul mais l’attribut système a fait que mes partages montés par cifs le sont correctement (rwxr-xr-x).

S’en est suivi sur la liste de propositions pour faire en sorte que cifs n’efface le “write bit” quand il y a l’attribut de lecture seule…

voilà pour l’info. thread close :wink: