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

FrancisFDZ · Le 01/06/2022, à 07:50

Depuis un bon moment, ce post devient une discussion de spécialistes sur le pourquoi du comment et les détails des fichiersrépertoires récalcitrants Où en est @marcusbaslerus, la victime de ces problèmes, et comment a-t'il avancé depuis sa dernière intervention ?

marcusbaslerus · Le 01/06/2022, à 20:45

Bonjour à tous,

Désolé de ne pas suivre toutes vos réponses instantanément.

Concernant le fichier /etc/exports du côté serveur NFS c'est vrais que je n'avais donné que la ligne que j'y ai ajoutée. Je n'avais pas tout de suite compris que vous vouliez voir le contenu de tout le fichier (je n'ai pas mon ancien ordinateur sous la main aujourd'hui).

Par rapport au droit sur les 140 dossiers qui posaient encore problèmes, j'ai omis de préciser qu'ils avaient aussi les droits d'exécutions, méaculpa.

Voici ce que j'ai fait dernièrement :

J'ai vérifié les UID, ils correspondent bien à 1000 pour l'utilisateur marc sur l'ancien et le nouvel ordinateur.

J'ai repéré ce qui appartenait à root dans mon dossier home/marc, il s'agissait de fichiers .log que j'avais créé par des lignes de commandes et d'un dossier vide (.gvfs) et de 3 sous-dossiers de .cache . J'avais aussi une copie d'un répertoire d'un autre utilisateur (copié par erreur et oublié) Tout ça n'a plus d'intérêt actuellement, je les ai effacé.

J'ai laissé tombé le NFS, j'ai installé le serveur SSH sur mon ancien ordinateur, puis j'ai exécuté sur mon nouvel ordinateur :

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

Le .log généré comporte dans les 200 000 lignes, à la fin du fichier, on peu lire :

sent 3,643,464 bytes  received 34,278,919,321 bytes  11,650,828.47 bytes/sec
total size is 89,676,960,076  speedup is 2.62

Il ne contient pas de message d'erreur.

Pour pouvoir comparer la taille de mon ancien dossier home et de la copie sur le nouvel ordinateur, je me suis déconnecté de mon compte sur l'ancien ordinateur et sur le nouveau j'ai exécuté :

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

Les deux dossiers contiennent le même nombre d'éléments.

Après avoir démarré mon nouvel ordinateur sur un live-USB, j'ai enlevé certain répertoire caché de /home/marc-new pour les remplacer par une copie de ceux d'une session vierge /home/marc (créée avec le même mot de passe que sur l'ancien ordinateur) sur ce même ordinateur (il s'agissait de tous ceux présents dans /home/marc sauf .cache).
J'ai ensuite renommé /home/marc en /home/marc-old puis /home/marc-new en /home/marc. Après avoir redémarré, j'avais accès à mes e-mails et à mon historique (et onglets ouverts) comme sur mon ancien ordinateur (je n'ai pas mon fond d'écrans, mais ça, ce n'est vraiment pas grave).

Je ne sais pas si je dois marquer résolu sur mon poste ? J'ai réglé mon problème, mais concernant NFS on est dans le flou.

Merci encore pour votre aide et tous vos messages,
Marc.

Dernière modification par marcusbaslerus (Le 01/06/2022, à 20:48)

Coeur Noir · Le 01/06/2022, à 21:44

C'est donc à priori la piste de Bruno, à propos de NFS, qui devait être la plus probable.

T'excuse pas ;-) t'y es pour rien si on digresse à mille à l'heure !

geole · Le 02/06/2022, à 10:08

marcusbaslerus a écrit :

Voici ce que j'ai fait dernièrement :
....
J'ai laissé tombé le NFS, j'ai installé le serveur SSH sur mon ancien ordinateur, puis j'ai exécuté sur mon nouvel ordinateur :
sudo rsync -av marc@169.254.25.4:/home/marc/ /home/marc-new/ > rsync_home_5.log 2>&1
Il ne contient pas de message d'erreur.
Marc.

L'important ait que tu ais réussi le transfert!
Mais cela me semble un pur hasard. Tu as probablement remis en état sans le savoir.
Voir cet exemple

a@p:~$ sudo rsync -ahvx --progress --stats --exclude '.*' --exclude 'persistence.*' --delete-before a@b:/home MAISON
a@b's password: 
receiving file list ... 
rsync: readlink_stat("/home/a/READ/read.txt") failed: Permission denied (13)
491 files to consider
IO error encountered -- skipping file deletion
                    
Number of files: 491 (reg: 349, dir: 126, link: 16)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 0
Total file size: 48.13M bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 11.26K
File list generation time: 0.005 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 54
Total bytes received: 11.27K

sent 54 bytes  received 11.27K bytes  3.23K bytes/sec
total size is 48.13M  speedup is 4,251.70
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3]
a@p:~$

marcusbaslerus · Le 02/06/2022, à 13:45

geole a écrit :

Mais cela me semble un pur hasard. Tu as probablement remis en état sans le savoir.

J'ai écrit que j'ai enlevé des fichiers et dossiers qui n'appartenait pas au user "marc", mais je précise que les derniers répertoires qui bloquait appartienne bien au user "marc" et je n'y ai pas touché avant d'avoir essayé avec SSH.

Coeur Noir · Le 02/06/2022, à 14:35

Bah idéalement pour avoir le fin mot de l'histoire, il aurait fallu voir les droits et permissions dans l'emplacement « original » avant tout éventuelle modification.

De là on aurait pu déterminer ce qui coince, sur la base de ces 2 hypothèses :
⋅ des éléments appartiennent à root ( ce qui est déjà anormal, puisqu'il s'agissait d'un répertoire personnel… )
⋅ sur des éléments appartenant à marc ( ou tout utilisateur d'uid 1000 ) des droits inadéquats ou trop restrictifs dans le cadre de la copie envisagée.

Là on ne pourra plus savoir. Et c'est pas grave, ça frustre notre curiosité de maniaques mais tu es parvenu à tes fins ;-)

Tu aurais pu nous en dire davantage sur ton contexte, sur les raisons qui t'ont amené à procéder de la sorte ( j'ai l'impression que tu t'es terriblement compliqué la vie, au final ).
Ma suspicion : tu ne parvenais plus à démarrer la session graphique de marc sous ta 18.04…

marcusbaslerus · Le 02/06/2022, à 15:04

Coeur Noir a écrit :

Ma suspicion : tu ne parvenais plus à démarrer la session graphique de marc sous ta 18.04…

Pas du tout, mais je ne connaissais pas plus NFS que SSH et je croyais que NFS serais un peu plus trivial que ça (je connaissais un peu Samba, mais j'avais déjà galéré avec).
Cette mésaventure m'a permis de voir comment utiliser SSH qui, du coup, est carrément plus trivial, totalement différent des protocoles du type : 1) partage un répertoire sur un serveur 2) accès... mais beaucoup plus puissant et a priori sécurisé (pour mon appli, je m'en foutais de la sécurité, mais c'est bon à savoir)

bruno · Le 02/06/2022, à 16:18

geole a écrit :

marcusbaslerus a écrit :
Voici ce que j'ai fait dernièrement :
....
J'ai laissé tombé le NFS, j'ai installé le serveur SSH sur mon ancien ordinateur, puis j'ai exécuté sur mon nouvel ordinateur :
sudo rsync -av marc@169.254.25.4:/home/marc/ /home/marc-new/ > rsync_home_5.log 2>&1
Il ne contient pas de message d'erreur.
Marc.
L'important ait que tu ais réussi le transfert!
Mais cela me semble un pur hasard. Tu as probablement remis en état sans le savoir.

Non ce n'est pas un hasard. Il faut et il suffit que marc ait les droits en lecture sur tous les fichiers de la source (169.254.25.4:/home/marc/) et que l'utilisateur qui lance rsync (ici root via sudo) ait les droits en écriture sur la cible (/home/marc-new/)

geole a écrit :

Voir cet exemple

a@p:~$ sudo rsync -ahvx --progress --stats --exclude '.*' --exclude 'persistence.*' --delete-before a@b:/home MAISON
a@b's password: 
receiving file list ... 
rsync: readlink_stat("/home/a/READ/read.txt") failed: Permission denied (13)
…

Au vu de l'erreur, /home/a/READ/read.txt est probablement un lien symbolique non sécurisé.

man rsync a écrit :

Symbolic links are considered unsafe if they are absolute symlinks (start with /), empty, or if they contain enough ".." components to ascend from the directory being copied.

Dernière modification par bruno (Le 02/06/2022, à 16:20)

geole · Le 02/06/2022, à 16:40

Bonjour
D'abord, le transfert des fichiers appartenant à root ne pose aucun problème par NFS puisque la commande rsync est lancée par sudo. Je l'ai montré hier.

user1000@c:~$ ls -ls /media/DoubleMaison/Maison/a | grep RO
 4 drwxr-xr-x  3 root     root      4096 mai   30 19:25 ROOT

et j'ai expliqué pourquoi il y avait cette erreur

rsync: readlink_stat("/home/a/READ/read.txt") failed: Permission denied (13)

==> Le répertoire émetteur READ est en lecture seule.… et son double est bêtement mis aussi en READ. Donc impossibilité d'y créer ultérieurement des fichiers!

Ensuite, il faut considérer que le SSH n'est absolument pas sécurisé. L'utilisateur à distance dispose de tous les droits. Il doit simplement connaître le mot de passe de l'utilisateur serveur.
A mon avis, pour un usage au quotidien, il est préférable d'utiliser NFS. On peut fournir la liste des répertoires à traiter et même les mettre en lecture seule. De plus l'utilisateur client ne connaît pas le mot du serveur.

Nota ce matin j'ai installé SSH serveur.

bruno · Le 02/06/2022, à 17:04

geole a écrit :

Ensuite, il faut considérer que le SSH n'est absolument pas sécurisé. L'utilisateur à distance dispose de tous les droits. Il doit simplement connaître le mot de passe de l'utilisateur serveur.
A mon avis, pour un usage au quotidien, il est préférable d'utiliser NFS. On peut fournir la liste des répertoires à traiter et même les mettre en lecture seule. De plus l'utilisateur client ne connaît pas le mot du serveur.

Ça c'est du grand n'importe quoi…
SSH est parfaitement sécurisé, surtout lorsque l'on désactive l'on autorise que l'authentification par clés. Et je ne sais pas trop ce que tu appelle l'utilisateur distant. Il y a un utilisateur local qui lance lance la commande sur le client et un utilisateur distant qui est celui qui se connecte au serveur toto@serveur et même si c'est root je ne vois pas le problème.
Par contre NFS ne propose de sécurité qu'au niveau du réseau, pas des utilisateurs (sauf à utiliser kerberos pour authentifier) et le protocole n'est pas chiffré. En plus j'ai expliqué les problèmes que cela pouvait poser avec le mappage des identifiants utilisateurs. Bref de base, cela ne doit jamais sortir d'un réseau privé.

Dernière modification par bruno (Le 02/06/2022, à 17:10)

geole · Le 02/06/2022, à 20:22

Hors sujet.
Je ne discute pas des nécessités de sécurité d'une entreprise multinationale.
Mais d'un simple particulier qui a dans une même piêce deux ordinateurs et une box pour les relier avec des câbles.

Tu nies le fait que l'installation standard est basée sur le mot de passe et pas le chiffrement.

Tu sembles croire que même sous windows le logiciel fonctionne à merveille grâce à wsl. J'ai eu trop de déboires avec ce produit et je ne regarde même plus ce qu'il devient. Donc du samba ou du nfs.
et je laisse ssh aux ordinateurs dédiés à l'hébergement de données.

Je n'ai pas trouvé dans la documentation le montage automatique au démarrage de l'ordinateur.. Un oubli?
Fin d'intervention dans cette discussion.

Dernière modification par geole (Le 02/06/2022, à 20:31)

MicP · Le 02/06/2022, à 21:46

Bonjour

SSH et NFS n'ont pas du tout la même fonction,
même si NFS peut utiliser SSH pour chiffrer sa communication.

SSH <=> Secure SHell
NFS <=> Network File System

Quand l'authentification <=> qui permettra l'accès,
c'est tout-à fait autre chose et il n'y a pas que les clef SSH qui peuvent êtres utilisées pour ça.

Coeur Noir · Le 03/06/2022, à 00:07

marcusbaslerus a écrit :

Coeur Noir a écrit :
Ma suspicion : tu ne parvenais plus à démarrer la session graphique de marc sous ta 18.04…
Pas du tout

Ah. J'aurais cru, vu le détour quelque peu abracadabrantesque que tu as suivi pour récupérer ce $HOME ( suffisait de le coller dans un DD externe, par ex. )

Mais tu as raison : alors que NFS est censé être « la voie royale » pour partager des ressources sous Linux dans un réseau local, sa mise en place est tout sauf tranquille ( zéro outil « ergonomique » pour aider. )

Et curieusement, tu aurais très bien pu t'en sortir sans jamais ouvrir un terminal ni passer une commande via samba - n'en déplaise à QiD…
D'un côté en partageant le dossier adéquat d'un clic droit dans Nautilus,
de l'autre, toujours dans Nautilus, en te connectant via « Réseau » à ce dossier, en indiquant son chemin genre smb://ip_machine_distante/dossier_partagé

Dernière modification par Coeur Noir (Le 03/06/2022, à 00:10)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 01/06/2022, à 07:50

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

#52 Le 01/06/2022, à 20:45

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

#53 Le 01/06/2022, à 21:44

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

#54 Le 02/06/2022, à 10:08

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

#55 Le 02/06/2022, à 13:45

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

#56 Le 02/06/2022, à 14:35

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

#57 Le 02/06/2022, à 15:04

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

#58 Le 02/06/2022, à 16:18

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

#59 Le 02/06/2022, à 16:40

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

#60 Le 02/06/2022, à 17:04

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

#61 Le 02/06/2022, à 20:22

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

#62 Le 02/06/2022, à 21:46

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

#63 Le 03/06/2022, à 00:07

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

Pied de page des forums