[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Conservation des droits samba



Le Wednesday 25 March 2009 19:32:31 mathias dufresne, vous avez écrit :
> Salut,
>
> Si je résume on a un serveur de fichier d'entreprise sous GNU/Linux qui
> distribue des fichiers à des Windows.
>
> la question c'est d'arriver à recopier une arborescence type en gardant les
> droits pour n'avoir qu'à la renommer.
>
> Je n'ai pas beaucoup joué avec Samba ces dernières années, l'état de l'art
> à pu fortement évoluer depuis, mais j'avais rencontré des difficultés avec
> les ACL sur système de fichiers Unix au travers de Samba (difficultés
> d'affichage, de mise à jour...), si ce n'est pas pleinement résolu il
> existe ntfs-3g qui permet à un Linux de gérer le NTFS complètement, ce
> serait peut-être intéressant dans ton cas...

Attention, ntfs-3g ne gère pas les ACL et propriétaires...
Ca permet juste d'accéder aux fichiers, ce qui est déjà pas mal.
Bref, ce n'est pas fait pour autre chose que dépanner un Windows, ou partager 
une partition entre deux OS sur un même ordinateur.

> Pour ta problématique je passerai par une archive (rar, zip mais bon, tar
> c'est mieux :p) qui devrait te garder les droits voire les dates de tes
> fichiers. Je n'ai jamais testé pour zip et rar, mais tar conserve tout cela
> gentillement.
> Comme ça un bon vieux copier/coller mais avec le bouton droit -> "extraire
> ici" et c'est fini : )

Ni tar, ni zip ne stockent les ACL.
Bien que dans l'exemple il ne semble pas y avoir d'ACL, seulement des groupes.
Pour sauvegarder les ACLs, deux solutions :
- utiliser un archiveur qui les supportent : star, dar, pax
- sauvegarder les ACLs à part avec getfacl et les réappliquer avec setfacl.

Sur le fond du problème maintenant, je pense que les droits et surtout les 
proprétaires (groupes) ne sont pas conservés parceque l'utilisateur qui fait 
la manip n'est pas root coté Unix.
Coté Unix en ligne de commande, on a le même comportement avec des groupes 
auxquels on n'appartient pas :

Le compte gilles appartient à audio, mais pas à gmocelli :

$ touch test
$ sudo chgrp gmocelli test
$ ll test
-rw-r--r-- 1 gilles gmocelli       0 mar 25 22:11 test
$ cp -a test test2
$ ll test*
-rw-r--r-- 1 gilles gmocelli 0 mar 25 22:11 test
-rw-r--r-- 1 gilles gilles   0 mar 25 22:11 test2

En root, ça marche :
$ sudo cp -a test test2
$ ll test*
-rw-r--r-- 1 gilles gmocelli 0 mar 25 22:11 test
-rw-r--r-- 1 gilles gmocelli 0 mar 25 22:11 test2

Avec un groupe auquel on appartient, ça marche :
$ chgrp audio test
$ ll test
-rw-r--r-- 1 gilles audio         0 mar 25 22:11 test
$ cp -a test test2
$ ll test*
-rw-r--r-- 1 gilles audio       0 mar 25 22:11 test
-rw-r--r-- 1 gilles audio       0 mar 25 22:11 test2


Deuxième point, Windows veut absolument changer le groupe propriétaire 
(généralement, on se retrouve avec Utilis. du domaine... Pas top.
Ce que je fais, c'est d'enlever les droits au groupe propriétaire et à autre,
Comme ceci :

exemple            drwx------+     proprio:users
   |-dossier1       drwx------+     proprio:users
   |-dossier2       drwx------+     proprio:users
   |-dossier3       drwx------+     proprio:users

J'ai mis un + comme le fait ll sous Linux quand il y a des ACLs.
Et on ajoute les 2 ACLs suivantes à chaque sous-répertoire :
$ setfacl -m d:g:groupe1:rwx dossier1
$ setfacl -m g:groupe1:rwx dossier1

On donne les droits au groupe sur le répertoire, et on met un ACL par defaut 
avec ces mêmes droits à ce groupe. Ce qui fait que tout nouveau fichier ou 
répertoire héritera de cette ACL.

Si l'utilisateur que fait la copie fait parti des groupes en question, la 
copie devrait garder les ACL.

Attention peut-être à l'interaction avec les paramêtres "inherit permissions", 
"inherit owner" et "inherit acls".

J'espère ne pas avoir dit de grosses bétises...


Reply to: