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

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

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...

Ce qui chagrine marcusbaslerus - son vrai problème - c'est qu'il ne parvient pas à copier intégralement le dossier $HOME visé.

Ça n'a fort probablement aucun rapport avec NFS, ssh ni APIPA si ce problème de permission denied provient de « plus haut / avant » ( droits, système de fichiers ). À vérifier donc.

Marcusbaslerus rendez-vous au #9 pour réduire les hypothèses.

Si ça invalide les hypothèses - pourquoi pas ! - alors Bruno semble dire que NFS n'est pas la méthode de partage à privilégier ( ou avec d'autres options de montage ).
T'as pas un disque dur externe sous le coude ? Une clé USB avec une Ubuntu 22.04 que tu pourrais lancer en live-session sur la machine problématique ?

Car est-ce bien ça le contexte : une machine qui va mal où tu veux récupérer tes affaires, et une machine qui va bien où tu veux importer ces affaires ?

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

geole · Le 30/05/2022, à 18:07

marcusbaslerus a écrit :

ajouté cette ligne à /etc/fstab :
169.254.25.4:/home/ /media/marc/NFS nfs defaults,user,auto,_netdev,rsize=16384,wsize=16384
Marc.

Bonjour
As-tu essayé

169.254.25.4:/home/ /media/marc/NFS nfs defaults,user,auto,_netdev,bg

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

Rappel de codification
-a, --archive archive mode; equals -rlptgoD

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

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

Purée les gars… chaque chose en son temps.

Les vérifications fondamentales d'abord, puisque tout ce qu'on a c'est Permission denied (13).

Ensuite est-ce que les options de rsync sont les bonnes ?
Pourquoi seulement -av et pas -rav : est-ce que ça n'oublierait pas de synchroniser le contenu des dossiers dans un cas ?
→ non, voir réponse de geole ( merci ), juste au dessus,
→ du coup le x est-il absolument nécessaire ( puisqu'il y a déjà l dans a ) ?

Enfin si tout ça tombe à l'eau, étalez vos connaissances de NFS et ssh. Pas avant ( parce que si des dossiers sont pas « traversables » le problème persistera… )

Marcusbaslerus rendez-vous au #9 pour réduire les hypothèses.

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

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

pour rsync ce sera sans moi : trop complexe à improviser... je préfère grsync qui te redonnera bien la commande rsync qu'il exécute mais que de toutes façon je ne mémorise pas...

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

rsync: [sender] send_files failed to open "/media/marc/NFS/marc/.Xauthority": Permission denied (13)

L'emplacement du point de montage ( ici NFS, dans /media/marc/ ) ne serait-il pas problématique, aussi, ou relève-t-il d'un automatisme quelconque de NFS, Bruno ?
Le dossier /media/$USER servant automatiquement à udisks / usdisksctl pour les montages automatiques de supports nomades connectables à chaud, c'est pas toujours une bonne idée d'y ajouter manuellement des dossiers.

ls -la /media/marc/NFS

pour vérifier la présence d'ACL sur …/marc/… et à cet endroit NFS risque d'être inaccessible aux autres ( souhaitable ou pas ? ) quoi que ça n'empêcherait pas root d'y écrire…

Par ailleurs

…/NFS/marc/.Xauthority

est un fichier, pas un répertoire, qui doit absolument appartenir à l'$USER pour pouvoir lancer sa session graphique… tu veux bien nous en dire plus sur l'état de ta 18.04, Marc ?

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

Qid · Le 30/05/2022, à 19:15

Coeur Noir a écrit :

tu veux bien nous en dire plus sur l'état de ta 18.04, Marc ?

il va effectivement falloir nous faire un état des lieux parce que là nous on tourne en rond...
faut vraiment qu'on regarde l'état de ton système de départ parce que ça sert a rien de récupérer une épave... c'est effectivement comme on l'a déjà dit un coups à foirer ton système d'arrivée aussi

bruno · Le 30/05/2022, à 19:25

J'ai déjà donné une solution possible en #4 : il faut utiliser no_root_squash. S'il y a encore des erreurs « permission denied » c'est certainement parce qu'il y a des fichiers en lecture seulement pour leur propriétaire et avec des UID/GID qui ne sont pas identiques sur le serveurs et le client (lire man exports). Il faudrait vérifier les UID sur le serveur (pas sur le point de montage où ils sont « mappés ») et sur le client. Mais encore une fois se serait beaucoup plus simple avec SSH…

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

bruno a écrit :

encore une fois se serait beaucoup plus simple avec SSH…

oui mais ce serait moins drôle... on va pas perpétuellement refaire le débat ssh/sshfs/sftp vs nfs...

Coeur Noir · Le 30/05/2022, à 22:08

bruno a écrit :

J'ai déjà donné une solution possible en #4 : il faut utiliser no_root_squash. S'il y a encore des erreurs « permission denied » c'est certainement parce qu'il y a des fichiers en lecture seulement pour leur propriétaire et avec des UID/GID qui ne sont pas identiques sur le serveurs et le client…

Mouais, la probabilité la plus probable, c'est quand même qu'il n'y ait jamais eu qu'un seul utilisateur sur chaque machine, à chaque fois le premier et seul créé, soit uid 1000 de part et d'autre.
À vérifier.

QiD a écrit :

ça sert a rien de récupérer une épave... c'est effectivement comme on l'a déjà dit un coups à foirer ton système d'arrivée aussi

Dans un $HOME la plupart des éléments visibles est récupérable car elle n'a pas d'impact sur le fonctionnement du système, ce sont les documents et médias divers - hors cas particuliers des scripts/programmes que l'utilisateur auraient créés. Les éléments cachés, eux, à part quelques exceptions ( profils de logiciels favoris un peu lourds à re-paramétrer ) sont bons à jeter quand on change d'OS ( ou de version d'OS ) - hors mise à niveau de version d'OS ou de logiciels déjà installés.

geole · Le 30/05/2022, à 22:45

marcusbasrelus a écrit :

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.
Marc.

Bonsoir,
puisque tu dis que le groupe n'a aucun droit de lecture pour ces répertoires, c'est ton droit.
Dans ce cas, tu les exclus de la commande rsync et tu fais une seconde commande rsync non précédée du mot sudo dédiée à ces répertoires.
Ou tu fais une entorse à ta sécurité en disant que root est autorisé à les lire.

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

Coeur Noir · Le 31/05/2022, à 02:53

Apparemment ça ne concerne pas que des dossiers ( on a un extrait des éléments en permission denied au #8 ) d'une part et d'autre part le fait que group et other n'aient aucun droit n'empêche pas l'utilisateur propriétaire de faire ce qu'il veut dans ces éléments ( si l'utilisateur a bien les droits rw- sur les fichiers et rwx sur les dossiers ).

Puisque la commande rsync -av est lancée avec les droits de root via sudo, elle traitera les éléments quel qu'en soit les propriétaires, en les conservant côté copie.

Si tu lances cette commande sans sudo, elle ne traitera que des éléments qui accordent le droit de lecture :
⋅ au même utilisateur propriétaire que celui qui lance la commande ( l'user d'uid 1000 à priori ) → éléments à minima en r-x------ pour les dossiers et r-------- pour les fichiers
⋅ au(x) membres du groupe propriétaire ( gid 1000 si on est dans la situation du groupe par défaut ) → r-xr-x--- dossiers, r--r----- fichiers
⋅ et aux autres → r-xr-xr-x dossiers, r--r--r-- fichiers [ n'importe qui peut lire donc copier des éléments avec de tels droits, qu'importe à qui ils appartiennent. ]

Dans un $HOME certains dossiers et fichiers restreignent légitimement les droits à l'utilisateur propriétaire uniquement ( .dbus, .gnupg, .Xauthority… )

Bref, tant qu'on ne verra pas un

ls -la /chemin/vers_ce/fameux/$HOME       # ou ls -lna /chem…

pour connaître avec certitude les propriétaires et les droits des divers éléments,
on ne pourra pas déterminer la propriété qui bloque la copie de ces éléments :
⋅ je pensais au droit d'exécution manquant sur certains dossiers, mais comme ça concerne aussi des fichiers, il doit y avoir une autre raison…
⋅ …autre raison suggérée 2 ou 3 fois par Bruno ( NFS où l'utilisateur root devient nobody si j'ai bien compris ) et ça pourrait coller, si on s'aperçoit que tous les éléments qui bloquent appartiennent initialement à root ( alors qu'ils ne devraient pas, vu où ils se trouvent. )

Dans ce cas, Bruno propose une autre option pour le montage NFS en #32 et #10.

Sinon, je propose de réapproprier tous les éléments de ce fameux $HOME à l'utilisateur d'uid 1000 ( puisque ça devrait être le cas de base dans cet emplacement… ) via :

sudo   chown   -R   1000   /chemin/vers_ce/fameux/$HOME

et là, à priori, même pas besoin de changer les options du montage NFS ( puisque les fichiers et emplacements appartiennent de part et d'autre à des utilisateurs d'uid 1000, ça on en est presque sûr ).

J'ajoute une commande au #9, du coup, et marcusbaslerus on attend impatiemment ton retour

______________________

Un peu HS :

geole a écrit :

Ou tu fais une entorse à ta sécurité en disant que root est autorisé à les lire.

Tu fais comment pour empêcher root de lire quoi que ce soit ?

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

Qid · Le 31/05/2022, à 06:33

Pour la partie de ton post de 23h08 qui me concerne je n'ai jamais dit le contraire mais tu as raison de le repréciser... Sinon pour ça :

Coeur Noir a écrit :

je propose de réapproprier tous les éléments de ce fameux $HOME à l'utilisateur d'uid 1000 ( puisque ça devrait être le cas de base dans cet emplacement… ) via :
sudo   chown   -R   1000   /chemin/vers_ce/fameux/$HOME

Suivant l'étendue de la catastrophe ça peut être une bonne idée... Celà dit ça ne résoudrait pas le souci de droit d'exécution des dossiers que tu signales depuis pas mal de post...

geole · Le 31/05/2022, à 10:01

geole a écrit :

marcusbasrelus a écrit :
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.
Marc.
Bonsoir,
puisque tu dis que le groupe n'a aucun droit de lecture pour ces répertoires, c'est ton droit.
Dans ce cas, tu les exclus de la commande rsync et tu fais une seconde commande rsync non précédée du mot sudo dédiée à ces répertoires.
Ou tu fais une entorse à ta sécurité en disant que root est autorisé à les lire.

Bonjour
Je confirme le refus de transfert puisque, après avoir installé le transfert de home j'ai le même incident pour les répertoires et fichiers appartenant exclusivement à l'utilisateur.
Voici les détails

sudo mount -av
....
mount.nfs: timeout set for Tue May 31 10:49:09 2022
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.21,clientaddr=192.168.0.25'
/Maison                  : successfully mounted
..... 
ls -ls /Maison
.4 drwxr-xr-x 32 1000 1000 4096 mai   31 08:39 a
..
a@a:~$ ls -ls /Maison/a/{MOI,snap}
ls: impossible d'ouvrir le répertoire '/Maison/a/MOI': Permission non accordée
ls: impossible d'ouvrir le répertoire '/Maison/a/snap': Permission non accordée 

ls -ls /Maison/a
  ...
      4 drwxrwxr-x 2 1000 1000       4096 avril 24 09:57 Documents
      4 drwxrwxr-x 2 1000 1000       4096 avril 23 15:46 DOWNLOAD
      4 drwxr-xr-x 3 root root       4096 mai   30 19:25 ROOT
      4 drwx------ 7 1000 1000       4096 mai   16 17:37 snap
  ...


id
uid=1005(a) gid=1005(a) groupes=1005(a),27(sudo)

Il me faut donc faire correspondre l'utilisateur 1005 du client, à l'utilisateur 1000 du serveur.

 grep uid /etc/exports
#/media/NosDonnees 192.168.0.0/32(rw,all_squash,anonuid=1000,anongid=1000,sync,no_subtree_check)
#/home 192.168.0.0/32(rw,all_squash,anonuid=1000,anongid=1000,sync,no_subtree_check)
/home 192.168.0.25(rw,anonuid=1005,anongid=1005

)
J'ai aussi essayé
/home 192.168.0.25(anonuid=1005,anongid=1005)
réflexion faite, cela serait plus logique de mettre le id du serveur plutôt que celui du client, et je vais enlever rw afin que le client ne modifie pas le serveur pour rester dans un strict contexte de duplication
Ne pas oublier cette commande après modification du fichier exports

sudo service nfs-kernel-server reload && showmount -e

Je vais tester plus tard.

Nota aucun problème de transfert pour les répertoires appartenant à "root"

C'est normalement prévu chez le serveur. Peut-être faut-il aussi quelque chose chez le client, ce qui me choquerait
J'ai donc mis a jour. Mais le problème persiste.
Cependant c'est la piste a creuser.

NOTA. De façon standard, mes données personnelles sont stockées dans une partition NTFS. Donc je n'avais pas de rsync inter-machine pour de l'EXT4

Dernière modification par geole (Le 31/05/2022, à 10:31)

iznobe · Le 31/05/2022, à 10:10

Dans le contexte du demandeur , on ne connait pas les UID sur serveur et stockage .

Comment tu fais correspondre les UID sur le serveur ? une option dans le fichier /etc/exports ?
je pense pas , qu ' il soit apres avoir fait correspondre sur le serveur l ' uid , utile de modifier quoi que ce soit sur le client ou le stockage .
De mon coté , j ' avais plusieurs fois testé , les options anonuid , anongid , sans pour autant que cela fonctionne correctement .
la seule façon que j' avais reussi a faire fonctionner ( au niveau des permissions ) , c ' etait de changer l ' UID de l ' utilisateur sur le serveur ou sur le client ( ainsi que les permissions de tous les fichiers lui appartenant bien sur ).

Dernière modification par iznobe (Le 31/05/2022, à 10:18)

Qid · Le 31/05/2022, à 10:59

iznobe a écrit :

Comment tu fais correspondre les UID sur le serveur ? une option dans le fichier /etc/exports ?

Bah... Je l'ai pas de tête mais pourtant si il me semble bien que ce sont les 2 options anon dans l'export qui résolvent le souci de droit... Ce qui me permet de rappeler qu'on attend toujours de voir le contenu du fichier export...

geole · Le 31/05/2022, à 12:30

A priori, problème résolu.
Sur le serveur

grep 25 /etc/exports
#/home 192.168.0.25(rw)  ==> Ne fonctionne pas
#/home 192.168.0.25(rw,anonuid=1000,anongid=1000)  ==> Ne fonctionne pas
/home 192.168.0.25(rw,all_squash,anonuid=1000,anongid=1000)  =>  Valeur bonne
#/home 192.168.0.25(all_squash,anonuid=1000,anongid=1000) => en cours de test

Je vais quand même vérifier si je peux mettre moins d'options
Sur le client

rsync -ahv  --progress  --exclude='*persistence.dat' --exclude='*/.*' /Maison /media/DoubleMaison
sending incremental file list
rsync: opendir "/Maison/a/MOI" failed: Permission denied (13)
rsync: opendir "/Maison/a/snap" failed: Permission denied (13)

sent 5.94K bytes  received 72 bytes  4.01K bytes/sec
total size is 24.35M  speedup is 4,047.51
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]

sudo rsync -ahv  --progress  --exclude='*persistence.dat' --exclude='*/.*' /Maison /media/DoubleMaison
sending incremental file list

sent 6.68K bytes  received 90 bytes  13.54K bytes/sec
total size is 24.35M  speedup is 3,596.22


ls -rls /media/DoubleMaison/Maison/a/MOI
ls: impossible d'ouvrir le répertoire '/media/DoubleMaison/Maison/a/MOI': Permission non accordée

sudo ls -Rls /media/DoubleMaison/Maison/a/MOI
/media/DoubleMaison/Maison/a/MOI:
total 4
4 drwx------ 2 1000 1000 4096 mai   31 08:40 sous-moi

/media/DoubleMaison/Maison/a/MOI/sous-moi:
total 0
0 -rwx------ 1 1000 1000 0 mai   31 08:40 fichier

id
uid=1005(a) gid=1005(a) groupes=1005(a),27(sudo)

Dernière modification par geole (Le 31/05/2022, à 12:58)

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

Qid a écrit :

Pour la partie de ton post de 23h08 qui me concerne je n'ai jamais dit le contraire mais tu as raison de le repréciser... Sinon pour ça :
Coeur Noir a écrit :
je propose de réapproprier tous les éléments de ce fameux $HOME à l'utilisateur d'uid 1000 ( puisque ça devrait être le cas de base dans cet emplacement… ) via :
sudo   chown   -R   1000   /chemin/vers_ce/fameux/$HOME
Suivant l'étendue de la catastrophe ça peut être une bonne idée... Celà dit ça ne résoudrait pas le souci de droit d'exécution des dossiers que tu signales depuis pas mal de post...

je ne le signale pas, je demande à ce que ça soit vérifié d'une part* et d'autre part si on digressait moins tu n'aurais pas oublié que j'ai déjà donné les manip's concernant les droits pour les dossiers, et je te laisse deviner : elles sont au message #9

* car vu le retour au #8 ça n'a pas l'air d'être ce que je crois puisqu'il n'y a pas que des répertoires là-dedans mais plutôt la suggestion de Bruno : les éléments en permission denied appartiennent probablement tous à root, root qui est « translaté » à nobody à travers NFS ( sujet que je ne maîtrise absolument pas. )

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

Geole, tu as l'air de démontrer que que ce que propose Bruno est pertinent :

bruno a écrit :

J'ai déjà donné une solution possible en #4 : il faut utiliser no_root_squash. S'il y a encore des erreurs « permission denied » c'est certainement parce qu'il y a des fichiers en lecture seulement pour leur propriétaire et avec des UID/GID qui ne sont pas identiques sur le serveurs et le client (lire man exports). Il faudrait vérifier les UID sur le serveur (pas sur le point de montage où ils sont « mappés ») et sur le client. Mais encore une fois se serait beaucoup plus simple avec SSH…

Par ailleurs chez toi, la source des données est sur du NTFS ( donc des inodes sans uid ni gid ) ce qui fait que ton exemple ne reproduit pas exactement les conditions de marcusbaslerus ( qui lui agit entre 2 systèmes de fichiers ext4 à priori ) → quelle influence sur ton choix d'options du montage NFS ? ( j'en sais rien, j'me dis juste que ça peut ne pas tout à fait correspondre à ce qui fonctionnera chez marcus. )

geole · Le 31/05/2022, à 16:27

Je ne sais pas où tu as vu que chez moi, la source d'essai des données est sur du NTFS.
J'ai dit que je sauvais mes données sur du NTFS. c'est tout: En Pratique, mes données stockées dans du NTFS sont sauvées régulièrement dans une partition NTFS d'un autre disque local par RSYNC et de temps en temps, transférées par réseau dans un ordinateur distant équipé d'un RAIDS EXT4. Le transfert se fait aussi par RSYNC. J'ai choisis NFS avec un ordinateur distant et SAMBA pour un autre ordinateur distant ( mon portable) qui n'a pas de raids.

J'ai fait le nécessaire ce matin pour prendre le HOME stocké dans une partition EXT4 du serveur.
J'ai donc du créer quelques répertoires dans la partition EXT4 du serveur. Il y avait déjà le répertoire SNAP qui refuse de se transférer (Il est presque un marqueur d'une partition EXT4) et j'ai transféré dans le HOME d'un autre O.S. pour essayer d'être le plus près possible du contexte.
C'est un coup de bol que les deux utilisateurs n'aient pas eu le même id!!!!
Je pense que c'est le problème de marcusbasrelus.

Oui c'est ce que bruno a dit. Ce sont trois options qui semblent fonctionner ensemble et que je découvre.
all_squash,anonuid=1000,anongid=1000
Dans l'était actuel des choses, cela semble vouloir dire que tous les utilisateurs du poste distant seront vus avec le uuid 1000 et le gid 1000
=> Donc tous les utilisateurs distants pourront accéder voir modifier. Alors qu'en local , il ne le pourront pas. Cela me fait profondément rire.

D'autre part, le serveur peut fournir une partition en mode lecture seule avec cette option.
/home 192.168.0.25(all_squash,anonuid=1000,anongid=1000)
donc sans rw. Cela peut être une sécurité. L'original n'est plus altérable par un ordinateur distant.

Je pense que la bonne solution est de faire le nécessaire pour créer sur le poste client un utilisateur ayant la bonne valeur du ID (probablement 1000?) s'il n'en existe pas un et ne de pas utiliser ce triplet d'options.

Il est logique d'avoir un refus de transfert des fichiers stockés dans un répertoire en lecture seule . Ce n'est pas spécialement un problème NFS car un RSYNC local a le même problème et l'utilisateur a le même problème s'il veut copier avec la commande cp son répertoire ailleurs. En effet, Il est logique de ne pas pouvoir créer des fichiers dans un répertoire en lecture seule. Mais les fichiers en lecture seule sont bien copiés.

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

a@a:/media/DoubleMaison/Maison/a$ ls -ls | grep READ
 4 dr--------  2 1000 root  4096 mai   31 17:48 READ
 4 -r--------  1 1000 1000     2 mai   31 18:55 READ.txt
a@a:/media/DoubleMaison/Maison/a$

Je crois que j'ai tout dit...

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

Coeur Noir · Le 31/05/2022, à 17:33

geole a écrit :

NOTA. De façon standard, mes données personnelles sont stockées dans une partition NTFS. Donc je n'avais pas de rsync inter-machine pour de l'EXT4

C'est ce NOTA que j'ai mal interprété. Au temps pour moi !

Ssh ( et sshfs, sftp ) au final une fois que les machines se connaissent / se parlent, y'a quasiment rien à configurer, contrairement à NFS.
Et bien que NFS est censé être un protocole typique Linux, il ne bénéficie d'aucun utilitaire graphique pour aider à le configurer ( alors que mettre en place des partages samba sous desktop Linux, ça peut se faire d'un clic droit - quand ça veut bien… )

Dans l'était actuel des choses, cela semble vouloir dire que tous les utilisateurs du poste distant seront vus avec le uuid 1000 et le gid 1000
=> Donc tous les utilisateurs distants pourront accéder voir modifier. Alors qu'en local , il ne le pourront pas

Oui c'est possible de faire du caca mais on n'est pas obligé ;-)
Ça veut sans doute dire que sans les options anon un utilisateur d'uid 1234 n'aura accès qu'à des données portant l'uid 1234 ?
Et que dans un contexte multi-machines, multi-utilisateurs, il faut organiser ces utilisateurs et groupes de la même façon partout - ce qui me semble une base saine ( l'utilisateur de tel nom aura le même uid sur tous les postes, les mêmes groupes existent sur tous les postes, avec les mêmes membres… )

Bref ta démonstration faite pour le NFS, bravo donc. Reste toujours à connaître avec certitude les « fondamentaux » chez Marc → les uid de part et d'autre, les droits et permissions des éléments qui bloquent ( objet du message #9 alors qu'on en est au #46 là. ) Avec ces infos, y'aura possibilité d'avancer.

Note aussi que je suggère de réattribuer à l'$USER tout le contenu de ce $HOME à copier - ce qui risquerait bien de faciliter les choses aussi, y compris dans ce contexte NFS.

Ou entre temps, Marc aura abandonné NFS pour tester en ssh, ou lancé une live-session-usb 22.04 sur sa machine 18.04, branché un DD externe et récupéré ses affaires…

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

Qid · Le 31/05/2022, à 18:02

Coeur Noir a écrit :

Ssh ( et sshfs, sftp ) au final une fois que les machines se connaissent / parlent, y'a quasiment rien à configurer, contrairement à NFS.
Et bien que NFS est censé être un protocole typique Linux, il ne bénéficie d'aucun utilitaire graphique pour aider à le configurer ( alors que mettre en place des partages samba sous desktop Linux, ça peut se faire d'un clic droit - quand ça veut bien… )

Franchement... J'espère que tu ne conseilles pas samba par ces propos... Parce-que perso moi je ne l'ai jamais compris ce protocole et même entre machines uniquement windows... Donc bon... Perso je n'ai pas confiance...

Coeur Noir · Le 31/05/2022, à 18:42

Franchement : où as-tu lu que je conseille samba ? Y'a même un petit « quand ça veut bien » dans le propos, histoire de ne pas inspirer trop confiance… [ edit, pour Qid : …à l'utilisateur linuxien néophyte qui voudrait se lancer dans la config' de samba ]
Je pointe juste cette bizarrerie : il y a / a eu sous ×buntu des assistants et des utilitaires pour aider à configurer samba, alors qu'il n'y en a pas pour nfs ( ça qui est montré dans la doc' n'a quasiment jamais fonctionné. )
Cela dit avec certaines précautions, samba fait le boulot… mais c'est hors sujet.

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

Qid · Le 31/05/2022, à 19:18

Coeur Noir a écrit :

Je pointe juste cette bizarrerie : il y a / a eu sous ×buntu des assistants et des utilitaires pour aider à configurer samba

Ouais mais comme tu le dis si bien si il n'est pas de confiance... Autant qu'il n'existe pas...

Coeur Noir · Le 31/05/2022, à 21:28

Ça n'est pas non plus ce que je dis… tu ne vois que ce que tu veux entendre d'où le « certaines précautions » qui t'a échappé :
ce seront ± les mêmes qu'il s'agisse de samba, nfs, ssh ou autres : soit davantage une question d'organisation des utilisateurs et des données, qu'une question de « protocole. »
Samba ( 3+ ) est sûr si on s'en sert bien tout comme nfs peut devenir une passoire si on s'en sert mal.

Autant qu'il n'existe pas...

Oublierais-tu que 99% des ordinateurs de bureau tournent sous Windows ? C'est quand même bien que le 1% et les 99% aient un moyen de communiquer. Et samba ne concerne pas que des ordinateurs à proprement parler.
On peut faire avec autre chose que samba, mais samba est présent par défaut dans beaucoup de machines - pas ssh, pas nfs ( même si Win sait faire ça aussi. )
Et viens pas troller sur les pourcentages évoqués, je sais qu'ils sont farfelus, ils donnent juste un ordre d'idées de grandeur à peu près réaliste.

Bref marcusbaslerus s'il revient n'est pas obligé de nous remercier pour les digressions hors sujet, et pourra nous trouver seulement difficiles à suivre…

Qid · Le 01/06/2022, à 07:30

Je savais que j'aurai dû rectifier mon précédent post qui a été écrit un peu trop vite... Il ne fallait effectivement pas t'attribuer la conclusion "Autant qu'il n'existe pas" qui là est bien la mienne... Et effectivement on va éviter de troller sur les outils windows... Enfin est-ce que c'est bien un troll à partir du moment ou on est très probablement tous d'accord sinon on ne serait pas sous Linux... Quant-à la dérive du sujet initial... Bah il est quand même toujours question de protocole d'échange de fichier entre machines... Et ce n'est pas moi qui ai commencé à dire que le choix de NFS n'était pas le meilleur... Et pour revenir dans le sujet je pense que notre demandeur ferait bien de tester son rsync en ssh pour se rendre compte que comme on l'a déjà dit de toutes façons le souci réel n'est très probablement pas lié au protocole utilisé mais à des soucis de droit sur la machine de départ...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

#29 Le 30/05/2022, à 18:35

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

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

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

#31 Le 30/05/2022, à 19:15

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

#32 Le 30/05/2022, à 19:25

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

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

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

#34 Le 30/05/2022, à 22:08

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

#35 Le 30/05/2022, à 22:45

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

#36 Le 31/05/2022, à 02:53

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

#37 Le 31/05/2022, à 06:33

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

#38 Le 31/05/2022, à 10:01

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

#39 Le 31/05/2022, à 10:10

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

#40 Le 31/05/2022, à 10:59

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

#41 Le 31/05/2022, à 12:30

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

#42 Le 31/05/2022, à 14:32

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

#43 Le 31/05/2022, à 14:54

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

#44 Le 31/05/2022, à 16:27

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

#45 Le 31/05/2022, à 17:33

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

#46 Le 31/05/2022, à 18:02

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

#47 Le 31/05/2022, à 18:42

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

#48 Le 31/05/2022, à 19:18

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

#49 Le 31/05/2022, à 21:28

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

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

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

Pied de page des forums