rsync via partage NFS retourne : "Permission denied (13)"

marcusbaslerus · Le 24/05/2022, à 12:49

Bonjour,
Je tente de copier le contenu de mon home depuis mon ancien ordinateur sous ubuntu 18.04 (ordi1) vers un nouvel ordinateur sous ubuntu 22.04 (ordi2).
J'ai relié les deux ordinateurs par un câble réseau croisé, changé les paramètres IPv4 et IPv6 en "réseau local seulement"
créé un serveur NFS sur ordi1,
ajouté cette ligne à /etc/exports :

/home 169.254.235.3(sync,no_subtree_check)

créé un client NFS sur ordi2,
ajouté cette ligne à /etc/fstab :

169.254.25.4:/home/ /media/marc/NFS nfs defaults,user,auto,_netdev,rsize=16384,wsize=16384

Ensuite j'ai exécuté sur ordi2

sudo rsync -a '/media/marc/NFS/marc/' /home/marc-new/ > rsync_home.log 2>&1

la copie obtenue est incomplète et je me retrouve avec 3654 lignes dans rync_home.log finissant toutes par

Permission denied (13)

je n'arrive pas à voir la différence entre ces fichiers et répertoires non copiés et ceux qui sont copiés (droits user, group = marc). La commande rsync a copié aussi bien des documents avec les droits user "marc" qu'avec les droits "root" et les a restitués avec les droits correspondants.
J'ai testé des copies de répertoires en fautes via l'explorateur de fichier graphique (Nautilus) cela fonctionne normalement.

Si vous avez une idée de la cause ? Un remède ?

Marc.

Dernière modification par marcusbaslerus (Le 24/05/2022, à 13:49)

geole · Le 24/05/2022, à 18:13

Bonjour
mets l'option -v
Tu auras alors probablement une piste ou publie un extrait de ce qui a été enregistré en erreur

Coeur Noir · Le 25/05/2022, à 02:18

Nota : appeler un chat, un chat.

1.
$HOME est une variable qui désigne le répertoire personnel de l'utilisateur courant, soit le dossier /home/$USER.
$USER est la variable qui désigne l'utilisateur courant.
Si on est dans la session de Noubie, $HOME renvoie donc au dossier /home/noubie et $USER au nom noubie.

Dans son répertoire personnel il y a toutes les données concernant un utilisateur.
Cet utilisateur en est le propriétaire, ce qui lui accorde le droit d'écrire-modifier-supprimer dans ce répertoire.
Il est aussi le propriétaire de tous les éléments contenus dans ce répertoire.

Dans un répertoire personnel il y a 2 « familles » de données, qui toutes concernent l'utilisateur :

les cachées qui sont les configurations, caches, paramètres… de tous les logiciels employés par l'utilisateur,
les visibles qui sont les document et médias créés, utilisés et gérés par l'utilisateur, directement ou à travers ses logiciels préférés.

Les documents et médias de l'utilisateur, généralement stockés dans les dossiers Bureau, Documents, Images, Modèles, Musique, Public, Téléchargements, Vidéos, sont les données visibles, sans dépendance particulière avec le système hôte, ce sont des données agnostiques.

Les configurations, caches, paramètres… toutes les données cachées, elles, dépendent de la version de l'OS hôte et des logiciels employés, elles sont spécifiques au contexte de l'utilisateur dans ce système.

Bref, c'est sans doute pas l'intégralité du $HOME qu'il faut récupérer tel quel, mais seulement les éléments visibles dans un premier temps.
Dans les éléments cachés, ne récupérer que ce qui sera vraiment utile dans le nouvel OS, par exemple les profils de certains logiciels que tu utilises beaucoup, si la montée de version desdits logiciels accepte encore des config's anciennes ( c'est souvent vrai mais pas toujours ! )

2.
$UID est la variable renvoyant l'identifiant numérique de l'utilisateur.
Cet identifiant numérique est porté par l'élément lui-même pour indiquer son utilisateur propriétaire,
contrairement à l'$USER ( le nom littéral ) qui est relatif au système local.
Les correspondances $UID↔$USER sont consignées dans le fichier /etc/passwd.

Pour que marc et marc-new puissent partager / utiliser des données de la même façon il faut impérativement que
⋅ dans chaque système marc et marc-new soient déduits d'un même $UID ( par exemple 1000 ),
⋅ les données elles-mêmes portent toutes cette même $UID comme utilisateur propriétaire.

Des

ls -lna /home/marc     # ou /home/marc-new

montreront les $UID plutôt que les noms littéraux, des fois que ce serait ça la différence…

Dernière modification par Coeur Noir (Le 25/05/2022, à 02:44)

bruno · Le 25/05/2022, à 07:53

Bonjour,

Il aurait fallu donner au moins une ligne complète d'erreur dans ton fichier de log, et oui l'option -v peut aider.

Ton problème de droits d'accès vient du partage NFS. Essaie avec le paramètre no_root_squash :

/home 169.254.235.3(sync,no_subtree_check,no_root_squash)

Explication : root_squash est le paramètre par défaut qui fait correspondre l'UID 0 (root) à l'utilisateur anonyme (nobody/nogroup) (cf man exports)

L’utilisation du partage NFS introduit une complication inutile et une source de problèmes. Il aurait fallu installer le serveur SSH sur ordi1, ouvrir un accès root et faire directement la copie depuis le client avec :

sudo rsync -av root@169.254.25.4:/home /home/marc-new/ > rsync_home.log 2>&1

MicP · Le 25/05/2022, à 09:31

Bonjour

Attention aussi à la confusion trop souvent faite entre $HOME et le répertoire /home/
parce que certains parlent de "dans ton home" quand ils ont la flemme d'écrire : "dans le répertoire /home/"
à moins qu'ils ne veuillent dire : "dans le répertoire personnel de ton compte utilisateur".

Dans le répertoire /home/ il y a les répertoires personnels de tous les comptes utilisateurs non privilégiés qui ont été créés sur la machine concernée :
par exemple, on y trouvera le répertoire /home/marc/ et aussi le répertoire /home/bruno/
et si le compte utilisateur marc a le droit d'accéder aux fichiers contenus dans le répertoire personnel de son compte utilisateur (<=> /home/marc/),
il n'aura sans doute pas accès aux fichiers contenus dans le répertoire /home/bruno/

Sans compter qu'il faudrait aussi que l'UID du compte utilisateur marc sur la machine source de la copie
soit le même que celui du compte utilisateur marc qui a été créé sur la machine cible de la copie.

Et ce sera le même problème que la copie soit faîte par SSH ou/et que l'accès au système de fichiers soit fait par NFS.

Là, la synchronisation est lancée avec les privilèges du compte super-utilisteur root (par sudo)
donc ce ne devrait pas être un problème d'attributs de propriété ou/et de groupe,
mais si le répertoire source ou/et le répertoire cible sont en train d'être utilisés,
il se peut que le problème vienne d'un des fichiers de cache d'une application, comme par exemple firefox
ou tout simplement l'application rsync qui est en train d'être utilisée.

Quoi qu'il en soit, on pourrait faire indéfiniment des hypothèses sans jamais tomber sur la "bonne"
ce qu'il faudrait, ce sont au moins les messages d'erreurs dans leur intégralité.

Dernière modification par MicP (Le 25/05/2022, à 11:09)

bruno · Le 25/05/2022, à 13:10

Sans compter qu'il faudrait aussi que l'UID du compte utilisateur marc sur la machine source de la copie
soit le même que celui du compte utilisateur marc qui a été créé sur la machine cible de la copie.
Et ce sera le même problème que la copie soit faîte par SSH ou/et que l'accès au système de fichiers soit fait par NFS.

Non pas tout à fait, j'ai expliqué rapidement un des écueils avec NFS (mise ne correspondance de l'utilisateur root avec l'utilisateur nobody par défaut). Avec rsync via SSH il y a des options comme --numeric-ids pour éviter les collisions de noms d'utilisateur. Quoi qu'il en soit, ici ce n'est pas forcément gênant puisque les données sont copiés dans un nouveau dossier, mais il faudra effectivement ensuite bien vérifier les propriétaire / groupe et éventuellement les changer.

Dernière modification par bruno (Le 25/05/2022, à 15:16)

MicP · Le 25/05/2022, à 13:56

Effectivement, tout est possible tant qu'on n'a pas vu le contenu du fichier /etc/exports et la configuration du serveur ssh (+ tout ce que j'oublie )

=======

Dans son message #1, marcusbaslerus a écrit :

… J'ai relié les deux ordinateurs par un câble réseau croisé, …

Ne t'embête plus avec ces histoires de cordon RJ45 droit ou croisé,
car de nos jours, un câble droit ou croisé fera très bien l'affaire dans tous les cas
étant donné que c'est une des cartes réseau qui détectera et fera automatiquement le croisement si nécessaire.
Voir : Wikipedia -> Auto MDI-X

marcusbaslerus · Le 30/05/2022, à 12:15

Bonjour,
Merci pour vos réponses et désolé de ne répondre que maintenant.

Concernant les données de configuration des logiciels, je suivrais le conseil de Coeur Noir, je ferais un peu de ménage avant d'utiliser réellement le répertoire copié.
J'ai fait un

ls -lna /home/marc

les UID sont bien tous à 1000 pour marc et 0 pour root (de même sur /home/marc-new).

J'ai fait un

sudo rsync -av '/media/marc/NFS/marc/' /home/marc-new/ > rsync_home_2.log 2>&1

la seule différence du .log généré avec le précédent est l'indication des répertoires et fichiers que rsync a copiés ou modifiés.

Voici un extrait du .log :

rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.ICEauthority": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.Xauthority": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.bash_history": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.gksu.lock": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.lesshst": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.viminfo": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.xsession-errors": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.xsession-errors.old": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/Ginkgo-marc": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/nohup.out": Permission denied (13)
rsync: [sender] opendir "/media/marc/NFS/marc/.PlayOnLinux/plugins/PlayOnLinux Vault/locale/fr" failed: Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.PlayOnLinux/plugins/Capture/LICENCE": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.PlayOnLinux/plugins/PlayOnLinux Vault/locale/default.po": Permission denied (13)
rsync: [sender] opendir "/media/marc/NFS/marc/.Skype" failed: Permission denied (13)
rsync: [sender] opendir "/media/marc/NFS/marc/.TrueCrypt" failed: Permission denied (13)
rsync: [sender] opendir "/media/marc/NFS/marc/.adobe" failed: Permission denied (13)
rsync: [sender] opendir "/media/marc/NFS/marc/.aptitude" failed: Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.VirtualBox/VBoxSVC.log": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.VirtualBox/VBoxSVC.log.1": Permission denied (13)
rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.VirtualBox/VBoxSVC.log.2": Permission denied (13)

Ensuite, sur les conseils de Bruno, j'ai changé la configuration du serveur NFS dans le fichier /etc/exports :

/home 169.254.235.3(sync,no_subtree_check,no_root_squash)

Et après avoir refait un

sudo rsync -av '/media/marc/NFS/marc/' /home/marc-new/ > rsync_home_3.log 2>&1

J'ai pu voir dans le .log qu'une grande quantité de fichiers/dossiers ont été copiés, mais il reste toujours 140 lignes avec "Permission denied", j'ai regardé leurs points communs : il s'agit uniquement de répertoire, droit user lecture/écriture, aucun droit pour group et other.

Merci pour le conseil sur les câbles croisé devenu inutile.

Je vais tenter d'utiliser un partage SSH, je vous tiens au courant.
Marc.

Coeur Noir · Le 30/05/2022, à 14:31

marcusbaslerus a écrit :

les UID sont bien tous à 1000 pour marc et 0 pour root (de même sur /home/marc-new).

Es-tu en train de dire que dans ces $HOME ( celui de marc et celui de marc-new ) il y a des éléments appartenant à root ?
Pas complètement normal… dans un $HOME tout est censé appartenir à son titulaire.

Depuis la session de l'utilisateur bidule

find /chemin/vers/dossier/ ! -user $USER

listera les éléments dans /chemin/vers/dossier/ n'appartenant pas à l'$USER qui lance la commande soit bidule.

Edit 2 : ou pour lister les éléments appartenant à root :

find /chemin/vers/dossier/ -user root

…y'a de bonnes "chances" que les 2 répondent la même liste mais avec la deuxième on sera fixé de suite sur le propriétaire.

140 lignes avec "Permission denied", j'ai regardé leurs points communs : il s'agit uniquement de répertoire, droit user lecture/écriture, aucun droit pour group et other.

Si les dossiers n'ont pas de droit exécution, il est impossible de les ouvrir !
Montre

ls -la /chemin/vers/dossier        # soit le chemin vers le $HOME que tu cherches à copier

les droits des dossiers devraient être
rwx------ à minima, ou plus courant rwxr-xr-x
Dans le premier cas, seul l'utilisateur propriétaire peut lire, écrire, ouvrir~lister~traverser le dossier, absolument rien pour tous les autres ( c'est donc très restrictif, par ex. dossiers ssh, gpg, private-keys… )
Dans le deuxième, l'utilisateur propriétaire peut lire, écrire, ouvrir le dossier, les membres du groupe et les autres peuvent lire et ouvrir le dossier ( mais pas y écrire ), c'est la situation basique.

Pour remettre le droit d'exécution UNIQUEMENT sur un_dossier et UNIQUEMENT pour l'utilisateur propriétaire :

sudo   chmod  u+rwx    /chemin/vers/un_dossier

Pour remettre le droit d'exécution sur un_dossier et UNIQUEMENT sur les dossiers qu'il contient, et UNIQUEMENT leur utilisateur propriétaire :

sudo   chmod  -R   u+rwX    /chemin/vers/un_dossier

-R pour agir récursivement ( sur et dans l'élément visé ) et X majuscule ( et non minuscule ) pour n'agir QUE sur les dossiers ( ou ne pas modifier les éléments qui ont déjà le droit d'exécution. )
sudo pas nécessaire si tu agis sur des éléments qui t'appartiennent.

Ce distinguo fichiers/dossiers n'est pas accessible via la notation en octal ( numérique ) des droits !

Selon les retours ( car je suspecte qu'on trouve aussi des éléments ne t'appartenant pas dans ce $HOME ) on pourrait aussi tout réattribuer à l'$USER, ce serait finalement plus simple. À voir.

Doc's → droits ⋅ permissions ⋅ autres droits

Edit 1 : L'idée c'est de vérifier ( et éventuellement réparer ) les droits et permissions dans le dossier $HOME que tu cherches à copier - donc les chemins pour y accéder sont à adapter, selon où tu montes ce $HOME ou si tu peux y accéder encore directement depuis la 18.04.

Dernière modification par Coeur Noir (Le 31/05/2022, à 02:54)

bruno · Le 30/05/2022, à 15:35

Re,

Encore une fois tu ne devrais pas utiliser un montage NFS pour faire cela mais une connexion SSH.
Maintenant si tu y tient absolument, essaie avec cette ligne pour le montage :

169.254.25.4:/home/ /media/marc/NFS nfs defaults,nfsvers=3,user,auto,_netdev,rsize=16384,wsize=16384

Coeur Noir · Le 30/05/2022, à 15:58

Je n'ai pas d'avis sur ce point ↑ Bruno, mais avant de conseiller l'un ou l'autre il me semble sage de vérifier les droits sur les dossiers qui bloquent, contrarié par cette remarque : « j'ai regardé leurs points communs : il s'agit uniquement de répertoire, droit user lecture/écriture ».

Si ces dossiers n'ont que lecture-écriture et pas exécution, qu'importe ssh ou nfs, ça bloquera…

iznobe · Le 30/05/2022, à 16:35

marcusbaslerus a écrit :

Bonjour,
Je tente de copier le contenu de mon home depuis mon ancien ordinateur sous ubuntu 18.04 (ordi1) vers un nouvel ordinateur sous ubuntu 22.04 (ordi2).
J'ai relié les deux ordinateurs par un câble réseau croisé, changé les paramètres IPv4 et IPv6 en "réseau local seulement"
créé un serveur NFS sur ordi1,
ajouté cette ligne à /etc/exports :
/home 169.254.235.3(sync,no_subtree_check)
créé un client NFS sur ordi2,
ajouté cette ligne à /etc/fstab :
169.254.25.4:/home/ /media/marc/NFS nfs defaults,user,auto,_netdev,rsize=16384,wsize=16384

Bonjour , ca parait bizzare ces 2 adresses ip dans tes commandes pour un reseau local .
Elles n' ont pas le meme masque ... et sont en 169.X.X.X .
je ne vois meme pas comment ca peut marcher de base .

Et sinon , effectivement , un dossier sans permission d ' execution , c ' est un dossier qui ne peut etre " traversé " ( on ne peut pas en voir le contenu ) .

Qid · Le 30/05/2022, à 17:06

iznobe a écrit :

marcusbaslerus a écrit :
Bonjour,
Je tente de copier le contenu de mon home depuis mon ancien ordinateur sous ubuntu 18.04 (ordi1) vers un nouvel ordinateur sous ubuntu 22.04 (ordi2).
J'ai relié les deux ordinateurs par un câble réseau croisé, changé les paramètres IPv4 et IPv6 en "réseau local seulement"
créé un serveur NFS sur ordi1,
ajouté cette ligne à /etc/exports :
/home 169.254.235.3(sync,no_subtree_check)
créé un client NFS sur ordi2,
ajouté cette ligne à /etc/fstab :
169.254.25.4:/home/ /media/marc/NFS nfs defaults,user,auto,_netdev,rsize=16384,wsize=16384
Bonjour , ca parait bizzare ces 2 adresses ip dans tes commandes pour un reseau local .
Elles n' ont pas le meme masque ... et sont en 169.X.X.X .
je ne vois meme pas comment ca peut marcher de base .

effectivement pour moi le souci est là : ce ne sont pas des adresses appliquées automatiquement en cas de non récupération par un serveur dhcp ça !? quand les ordis sont connectés l'un à l'autre sans routeur intermédiaire il me semble qu'il faut qu'ils soient tous les 2 en ip fixe...

MicP · Le 30/05/2022, à 17:13

Bonjour

Dans son message #12, iznobe a écrit :

… ca parait bizzare ces 2 adresses ip …

Ce sont des adresse du réseau 169.254.0.0/16 (Link-local addresses)
que les systèmes d'exploitations s'attribuent automatiquement et qui sont négociées entre les systèmes d'exploitation des machines directement interconnectées entre elles.

Voir APIPA : Automatic Private Internet Protocol Addressing

tu peux faire communiquer deux machines connectées l'une à l'autre par un simple cordon RJ45
ou plusieurs (65534) machines qui seraient interconnectées par un ou plusieurs simple HUB RJ45

Dernière modification par MicP (Le 30/05/2022, à 17:22)

iznobe · Le 30/05/2022, à 17:20

@ MicP : ok , ce n ' est donc pas un reseau local , mais du ad hoc non ?

sur ton lien :

APIPA (Automatic Private Internet Protocol Addressing) ou IPv4LL est un processus qui permet à un système d'exploitation de s'attribuer automatiquement une adresse IP, lorsque le serveur DHCP est hors service ou injoignable.

du coup ce n ' est meme pas du AD HOC , bref , je suis plutot largué avec ces adresses , mais ca n' a pas grand chose a voir avec le probleme de permissions de toute maniere .

Pour resoudre le probleme , voir le message ( et les commandes ) de @Coeur Noir #9.

Dernière modification par iznobe (Le 30/05/2022, à 17:24)

Qid · Le 30/05/2022, à 17:26

j'étais plus sûr pour le nom apipa mais c'est bien ce qu'il me semblait
en tous cas on est tout bien sur la même longueur d'onde à ce sujet...

Coeur Noir · Le 30/05/2022, à 17:34

APIPA
https://www.geeksforgeeks.org/what-is-a … ddressing/
https://www.it-connect.fr/adresse-apipa … -que-cest/
Donc plutôt normal s'il s'agit des 2 machines connectées physiquement entre elles, en dehors de tout autre réseau, confirmé par : « changé les paramètres IPv4 et IPv6 en "réseau local seulement" »
Et preuve que ce n'est pas le souci : les 2 machines communiquent et marcusbaslerus est bien parvenu à rsync des données entre elles - mais certaines données ne passent pas ( le problème est sans doute « sur » ces données non ? )

Il ne faut pas utiliser de telles adresses de façon permanente car ça n'est pas un adressage stable ( dès lors qu'un DHCP serait de nouveau opérationnel, elles ne sont plus utilisées. )
Attribuer une IP fixe à chaque machine serait effectivement plus « simple » car prévisible et stable.

→ Tant qu'il y a un doute sur les droits portés par les dossiers, c'est pas la peine de chercher plus loin : ça bloque dès le système de fichiers, quelle que soit la méthode de « partage » envisagée nfs, ssh ou autres, ça empêchera l'accès à ces dossiers ( s'ils n'ont pas d'exécution. )

→ Si on voit que les droits portés par les dossiers sont corrects, alors oui, vous pourrez chercher ailleurs des explications.

Les droits et permissions sont portés par les éléments eux-mêmes, c'est inscrit dans leurs inodes, ça fait partie des propriétés du système de fichiers.

Dernière modification par Coeur Noir (Le 30/05/2022, à 17:44)

MicP · Le 30/05/2022, à 17:41

Dans son message #15, iznobe a écrit :

… @ MicP : ok , ce n ' est donc pas un reseau local , mais du ad hoc non ? …

Si si, c'est bien un réseau local mais qui n'est pas routable sur internet.

On peut même renseigner le fichier /etc/hosts de chaque machine
pour donner un nom (sans avoir à utiliser un serveur DNS) à chacune des machines de ce réseau
en associant l'adresse IP (APIPA) de chaque machine à un nom de son choix.
Mais bien sûr, ce nom ne sera pris en compte que par la machine dans laquelle le fichier /etc/hosts est renseigné
Il suffit de renseigner le fichier /etc/hosts de chacune des machines de la même façon.

Dernière modification par MicP (Le 30/05/2022, à 17:57)

Qid · Le 30/05/2022, à 17:43

c'est sûr que si la communication entre les machines s'est bien faite on peut donc rester avec apipa mais bon... enfin tu as raison du coups le souci n'est pas là... sauf que dans ce cas le souci que tu décris n'a en réalité rien a avoir avec le besoin de départ... dans le sens ou ça sent le problème local bien complexe à remettre d'aplomb : toucher aux droits appliqués par défaut à ses dossiers de configurations n'est pas du tout une bonne idée quand on ne sait pas ce qu'on fait...

Coeur Noir · Le 30/05/2022, à 18:00

Mais pourquoi tu dis n'importe quoi ?

sauf que dans ce cas le souci que tu décris n'a en réalité rien a avoir avec le besoin de départ... dans le sens ou ça sent le problème local bien complexe à remettre d'aplomb

Le besoin de départ de marcusbaslerus c'est copier un $HOME d'une machine vers une autre.
Et il y arrive partiellement, la seule erreur ici, c'est qu'il y a des permissions denied sur certains éléments provenant d'un $HOME → ça, ça ne parle que de droits et permissions sur ces éléments, ça ne raconte rien qui serait en rapport avec un problème de communication entre les 2 machines. On n'aurait même pas l'info sinon !

D'où une première suggestion de vérifier les $UID de part et d'autres ( on a 1000 pour chaque utilisateur de chaque côté, ça simplifie les choses ) mais au passage ça semble montrer que des éléments dans un $HOME n'appartiennent pas à l'$USER de ce $HOME. Ça, ça n'est pas bloquant en soi puisque la commande utilisée est sudo rsync -av qui ne modifiera pas les propriétaires des éléments synchronisés mais on peut se demander pourquoi des trucs n'appartiendraient plus à son $USER dans un $HOME ( on en voit au #8 ).

Par contre, si on a des dossiers sans droit d'exécution ( quels que soient leurs propriétaires ) là forcément ça empêche d'utiliser ces dossiers… à vérifier, donc.

Dernière modification par Coeur Noir (Le 31/05/2022, à 04:24)

Qid · Le 30/05/2022, à 18:08

Coeur Noir a écrit :

ça semble montrer que des éléments dans un $HOME n'appartiennent pas à l'$USER de ce $HOME. Ça, ça n'est pas bloquant en soi [...] mais on peut se demander pourquoi des trucs n'appartiendraient plus à son $USER dans un $HOME ( on en voit au #8 ).

c'est bien ce que je dis : ce souci n'a quand même rien a avoir avec le fait de communiquer en réseau...
et palier ce souci en utilisant l'application avec sudo même si celle-ci est une application non graphique ne me semble pas être une bonne idée...

bref... tu as bien raison : ce serait bien de remettre les dossiers concernés par le problème d'aplomb...

Coeur Noir · Le 30/05/2022, à 18:18

Le but de marcusbaslerus n'est pas ( j'espère ) de réemployer tel quel tout ce $HOME importé depuis une 18.04 dans une version d'Ubuntu plus récente :

Concernant les données de configuration des logiciels, je suivrais le conseil de Coeur Noir, je ferais un peu de ménage avant d'utiliser réellement le répertoire copié.

Dans ce répertoire $HOME copié seules les données visibles-non-cachées sont réemployables et déplaçables sans conditions ( même pas besoin d'être root ).
Par contre, pour les données cachées, il faudra être plus sélectif et prudent et n'y reprendre que ce qui peut encore fonctionner dans la nouvelle Ubuntu ( par ex. ne surtout pas y reprendre le moindre élément relatif à l'env. graphique, ni les dossiers dconf, dbus, gnome et bien d'autres. )

Supposition de ma part : l'Ubuntu 18.04 d'où provient ce $HOME ne démarre plus en session graphique ;-)

Dernière modification par Coeur Noir (Le 30/05/2022, à 18:20)

bruno · Le 30/05/2022, à 18:24

Ce n'est pas un problème de droits sur le serveur, c'est un problème inhérent au fonctionnent de NFS et à la manière dont il met en correspondance les UID et GID entre le serveur et le client. Je vous invite à lire attentivement man exports à la section « User ID Mapping » et je rappelle que la commande rsync est lancée en tant que root.
Et c'est pour cela que je dis qu'il ne faut pas utiliser un montage NFS pour synchroniser des fichiers et dossiers appartenant à différents utilisateur (y compris root).

Le fait que le demandeur ait des trucs appartenant à root dans le dossier personnel d'un utilisateur standard n'arrange effectivement rien.

Dernière modification par bruno (Le 30/05/2022, à 19:38)

Qid · Le 30/05/2022, à 18:27

on avait quand même ça comme élément d'accroche dans le premier post...

marcusbaslerus a écrit :

Je tente de copier le contenu de mon home depuis mon ancien ordinateur sous ubuntu 18.04 (ordi1) vers un nouvel ordinateur sous ubuntu 22.04 (ordi2).

enfin là n'est pas le débat et pour ma part j'aurais plutôt tendance à faire les vérifications dans l'autre sens : "tout" copier et essayer ensuite puis seulement après dégager ceux qui auraient fait foiré... mais pour ça encore faut-il savoir à quoi se rapporte quoi... et ça ce n'est pas toujours facile...

Qid · Le 30/05/2022, à 18:34

bruno a écrit :

il ne faut pas utiliser un montage NFS pour synchroniser des fichiers et dossiers appartenant à différents utilisateur

mais là il est normalement bien question d'un utilisateur unique de chaque coté je pense...
et puis bon si le montage nfs est "bien fait"* normalement le changement d'user entre l'arrivée et le départ ne pose pas de souci : c'est comme ça que le montage des 2 parcs informatiques que je gère est conçu (même si ça marche entre les pc mais pas à partir de mon téléphone qui se log bien au nfs avec un des users qui pourtant a bien les droits... enfin on ne va pas débattre de mon cas ici car ce n'est pas le sujet...

edit : * : on a toujours pas le contenu du fichier export du serveur... élément qui est presque aussi important si ce n'est plus que le montage dans le client

Dernière modification par Qid (Le 30/05/2022, à 18:37)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 24/05/2022, à 12:49

rsync via partage NFS retourne : "Permission denied (13)"

#2 Le 24/05/2022, à 18:13

Re : rsync via partage NFS retourne : "Permission denied (13)"

#3 Le 25/05/2022, à 02:18

Re : rsync via partage NFS retourne : "Permission denied (13)"

#4 Le 25/05/2022, à 07:53

Re : rsync via partage NFS retourne : "Permission denied (13)"

#5 Le 25/05/2022, à 09:31

Re : rsync via partage NFS retourne : "Permission denied (13)"

#6 Le 25/05/2022, à 13:10

Re : rsync via partage NFS retourne : "Permission denied (13)"

#7 Le 25/05/2022, à 13:56

Re : rsync via partage NFS retourne : "Permission denied (13)"

#8 Le 30/05/2022, à 12:15

Re : rsync via partage NFS retourne : "Permission denied (13)"

#9 Le 30/05/2022, à 14:31

Re : rsync via partage NFS retourne : "Permission denied (13)"

#10 Le 30/05/2022, à 15:35

Re : rsync via partage NFS retourne : "Permission denied (13)"

#11 Le 30/05/2022, à 15:58

Re : rsync via partage NFS retourne : "Permission denied (13)"

#12 Le 30/05/2022, à 16:35

Re : rsync via partage NFS retourne : "Permission denied (13)"

#13 Le 30/05/2022, à 17:06

Re : rsync via partage NFS retourne : "Permission denied (13)"

#14 Le 30/05/2022, à 17:13

Re : rsync via partage NFS retourne : "Permission denied (13)"

#15 Le 30/05/2022, à 17:20

Re : rsync via partage NFS retourne : "Permission denied (13)"

#16 Le 30/05/2022, à 17:26

Re : rsync via partage NFS retourne : "Permission denied (13)"

#17 Le 30/05/2022, à 17:34

Re : rsync via partage NFS retourne : "Permission denied (13)"

#18 Le 30/05/2022, à 17:41

Re : rsync via partage NFS retourne : "Permission denied (13)"

#19 Le 30/05/2022, à 17:43

Re : rsync via partage NFS retourne : "Permission denied (13)"

#20 Le 30/05/2022, à 18:00

Re : rsync via partage NFS retourne : "Permission denied (13)"

#21 Le 30/05/2022, à 18:08

Re : rsync via partage NFS retourne : "Permission denied (13)"

#22 Le 30/05/2022, à 18:18

Re : rsync via partage NFS retourne : "Permission denied (13)"

#23 Le 30/05/2022, à 18:24

Re : rsync via partage NFS retourne : "Permission denied (13)"

#24 Le 30/05/2022, à 18:27

Re : rsync via partage NFS retourne : "Permission denied (13)"

#25 Le 30/05/2022, à 18:34

Re : rsync via partage NFS retourne : "Permission denied (13)"

Pied de page des forums