Bonjour,
je rencontre un probléme classique et connu, mais pour lequel je n’arrive pas à trouver de solution élégante.
Je fais un montage NFS d’un NAS synology sur mon desktop debian. Je fais ensuite les sauvegarde de desktop sur le NAS.
Le problème, c’est que les fichiers à sauvegarder appartiennent à plusieurs owner, dont root, et que NFD ne permet pas de les enregistrer en conservant l’UID et le GUID.
Comment contournez vous cette limitation (tout à fait logique ) ?
Salut,
Et, ceci de par quelle application logiciel ?
un classique rsync, via luckybackup.
Classique, non.
Quelles sont les options incluses au travers de cette interface ?
[mono]/source(s) /destination(s)[/mono] ?
Distant ? Local ?
ps : [mono]rsync[/mono] en mode console. 
je n’arrive pas à trouver quelles options de rsync sont utilisées précisément. J’ai précisé que je voulais conserver le groupe et le owner, c’est ça qui coince.
Huummm …
[quote]
-r, --recursive visite récursive des répertoires
-l, --links copie les liens symboliques comme liens symboliques
-p, --perms préserve les permissions
-t, --times préserve les dates
-g, --group préserve le groupe
-o, --owner préserve le propriétaire (root uniquement)
-D, --devices préserve les périphériques (root uniquement)[/quote]
La commande (tronquée)
Le probléme n’est pas rsync, mais NFS qui n’accepte pas que sync change le owner sur le rep monté.
Salut,
Je n’utilise pas NFS. (où plus, depuis bien trop longtemps)
Rsync, par défaut (sous wheezy et sauf erreur) à son propre groupe/user, en est-il de même sur ton NAS …
Re,
J’ai retrouvé mes notes sur le sujet.
Coté serveur.
Il est nécessaire d’éditer 3 fichier pour la configuration de notre serveur : [mono]/etc/exports, /etc/hosts.allow, /etc/host.deny[/mono].
[mono]/etc/exports[/mono]
C’est lui qui va permettre de définir quels sont les répertoires à partager et qui a quels droits dessus (on parle ici de clients et pas d’utilisateurs)
Pour de plus amples informations sur la gestion des droits, je vous invite à consulter les pages du manuel : man 5 exports
Attention !
Si : sur le serveur le répertoire partagé appartient à l’utilisateur 1002 et si vous donnez les droits d’écriture à l’hôte 192.168.0.11, l’utilisateur de cet hôte qui aura le droit d’écriture dans ce répertoire est celui dont le numéro, sur cet hôte, est 1002.
[mono]$ man 5 exports[/mono]
Extrait :
[quote] Correspondance d’ID utilisateur (« User ID Mapping »)
nfsd base son contrôle d’accès aux fichiers de la machine serveur sur l’UID et le GID fournis dans chaque requête RPC de NFS. Le comportement
attendu par un utilisateur est de pouvoir accéder à ses fichiers sur le serveur de la même façon qu’il y accède sur un système de fichiers normal.
Ceci exige que les mêmes UID et GID soient utilisés sur le client et la machine serveur. Ce n’est pas toujours vrai, ni toujours souhaitable.
Bien souvent, il n'est pas souhaitable que l'administrateur d'une machine cliente soit également traité comme le superutilisateur lors de l'accès
à des fichiers du serveur NFS. À cet effet, l'UID 0 est normalement transformé (« mapped ») en utilisateur différent : le prétendu utilisateur
anonyme ou UID nobody. C'est le mode de fonctionnement par défaut (appelé « root squashing »), qui peut être désactivé grâce à no_root_squash.
Par défaut, exportfs choisit un UID et un GID de 65534 pour l'accès « squash ». Ces valeurs peuvent également être définies par les options ano‐
nuid et anongid. Enfin, vous pouvez faire correspondre toutes les demandes des utilisateurs avec l'UID anonyme en indiquant l'option all_squash.
Voici la liste complète des options de correspondance (« mapping ») :
root_squash
Transformer les requêtes d'UID/GID 0 en l'UID/GID anonyme. Notez que ceci ne s'applique à aucun autre UID ou GID qui pourrait également
être sensible, tel que l'utilisateur bin ou le groupe staff par exemple.
no_root_squash
Désactiver la transformation du superutilisateur. Cette option est principalement utile pour les clients sans disque dur.
all_squash
Transformer tous les UID/GID en l'utilisateur anonyme. Utile pour les répertoires FTP publics partagés en NFS, les répertoires de spool de
news, etc. L'option inverse est no_all_squash, qui est celle par défaut.
anonuid et anongid
Ces options définissent explicitement l'UID et le GID du compte anonyme. Cette option est principalement utile pour des clients PC/NFS,
dans le cas où vous souhaiteriez que toutes les requêtes semblent provenir d'un seul et même utilisateur. Consultez par exemple la ligne
définissant le partage pour /home/joe dans la section EXEMPLES ci-dessous, qui attribue toutes les requêtes à l'utilisateur 150 (qui est
censé être celui de l'utilisateur Joe).
Tables d’exportation supplémentaire
Après avoir lu /etc/exports, exportfs lit les fichiers dans le répertoire des tables d’exportation supplémentaires /etc/exports.d… exportfs
concerne seulement un fichier dont le nom se termine par . exports et qui ne commence pas par . comme un fichier d’exportation supplémentaire. Un
fichier dont le nom ne satisfait pas à cette condition est simplement ignoré. Le format des tables d’exportation supplémentaire est le même que
/etc/exports.[/quote]
Si ce numéro ne correspond à aucun utilisateur sur l’hôte :
personne, pas même root, ne pourra écrire dans le dossier partagé à partir de cet hôte !
/etc/hosts.allow
Comme son nom l’indique, ce fichier va permettre de définir quels postes clients auront accès aux partages (quels postes seront autorisés à la connexion et à l’utilisation des services)
/etc/hosts.deny
Là aussi, comme son nom l’indique, ce fichier va permettre de définir quels postes clients n’auront pas accès aux partages (quels postes seront interdis à la connexion et à l’utilisation des services)
Pour de plus amples informations sur la gestion des access, je vous invite, là encore, à consulter les pages du manuel : man 5 hosts_acces
Sans omettre le fichier [mono]/etc/fstab[/mono].
Je connais tout ça, et c’est bien la qu’est le probléme. Les fichiers à sauvegader appartiennet à plusieurs users.
En relisant ta réponse, je me dis que je vais faire la liste des UID et GUID des users ayant des fichiers à sauvegarder, et donner touts les droits à ces UID/GUID sur le serveur (en fait, un NAS synology).
Je regarde ça ce soir.
J’ai tenté de lancer luckybackup en root , pas mieux, chgrp impossible.Je ne trouve pas d’options de mount qui pourrait correspondre à ce que je veux: pouvoir faire un chgrp vers un grp qui n’existe pas sur le server NFS.
Je suis repassé en nfsv3 coté serveur. Pour utiliser v4, il est préférable d’avoir un controleur de domaine afin que les utilisateurs soient les même coté client et serveur.
De plus j’ai fait un squash de root sur admin.
ça à l’air de passer pour le moment.