ssh et rsync sur un NAS UGreen

tintinux · Le 18/07/2025, à 11:17

Bonjour

Je n'arrive pas à comprendre la raison du message renvoyé par rsync quand je fais :

monuser@Hirondelle:~$ rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:/home/monuser/Documents/

rsync: [Receiver] mkdir "monuser/Documents" (in home) failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(1085) [Receiver=3.4.1]

Il me semble que le dossier existe bien et qu'il est accessible, et je le vérifie ainsi :

monuser@Hirondelle:~$ ssh monuser@serveur
monuser@serveur:~$ pwd

/home/monuser

monuser@serveur:~$ ls -l

total 4
drwxrwxrwx 4 monuser admin 4096 Jul 18 10:56 Documents

exit

Connection to nas closed.

monuser@Hirondelle:~$ scp /home/monuser/Documents/test.txt monuser@serveur:Documents

test.txt 100% 5 0.0KB/s 00:00
monuser@Hirondelle:~$

Vous auriez une idée ?
Merci !

Dernière modification par tintinux (Le 20/07/2025, à 10:00)

RaphaelG · Le 18/07/2025, à 12:20

Peut être en t'inspirant de ce que tu as fait avec scp ?

monuser@Hirondelle:~$ rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:Documents

Pour le '/' final, je ne crois pas qu'il soit nécessaire.

Dernière modification par RaphaelG (Le 18/07/2025, à 12:21)

iznobe · Le 18/07/2025, à 12:27

Bonjour , oui , mais bon ...

encore faut il etre connecté en SSH au serveur pour faire :

rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:/home/monuser/Documents/

....

Pour initier la connexion ssh au serveur en meme temps que la sauvegarde et lors de la commande rsync , il vaut mieux utiliser une commande du type :

rsync --progress -a -v --delete-after -e ssh $monuser@serveur:Documents

sinon , il faut initier la connexion SSH avant de lancer ta commande , lancer la commande , fermer la connexion .

Dernière modification par iznobe (Le 18/07/2025, à 12:40)

tintinux · Le 18/07/2025, à 13:32

RaphaelG a écrit :

Peut être en t'inspirant de ce que tu as fait avec scp ?
monuser@Hirondelle:~$ rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:Documents
Pour le '/' final, je ne crois pas qu'il soit nécessaire.

La commande

rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:Documents

me retourne un message d'erreur différent :
invalid path: 'Documents'
rsync error: errors selecting input/output files, dirs (code 3) at clientserver.c(2076) [Receiver=3.4.1]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [sender=3.2.7]

tintinux · Le 18/07/2025, à 13:37

iznobe a écrit :

encore faut il etre connecté en SSH au serveur pour faire :
rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:/home/monuser/Documents/
Pour initier la connexion ssh au serveur en meme temps que la sauvegarde et lors de la commande rsync , il vaut mieux utiliser une commande du type :
rsync --progress -a -v --delete-after -e ssh $monuser@serveur:Documents
sinon , il faut initier la connexion SSH avant de lancer ta commande , lancer la commande , fermer la connexion .

Je n'ai jamais eu besoin de me connecter préalablement avec -e ssh vers d'autres machines cibles.
Et si je l'ajoute, le message d'erreur est le même.

RaphaelG · Le 18/07/2025, à 16:31

iznobe a écrit :

.........
encore faut il etre connecté en SSH au serveur pour faire :
............

J'avais supposé que le daemon rsync.service tournait sur le serveur distant.

Dernière modification par RaphaelG (Le 18/07/2025, à 21:11)

tintinux · Le 18/07/2025, à 17:34

En ajoutant l'option -v j'ai les informations suivantes avant le message d'erreur :

ug_start_server, check access user: 1000, group: 10
getuid(): 1000 geteuid(): 1000
login group is admin, set euid as root
cannot set euid as root

Il faut que je précise que ma cible est un NAS Ugreen qui n'est pas sous Ubuntu mais sous une version non précisée de Debian.
Quand je fais la même chose avec un PC cible sous Ubuntu, je n'ai aucun souci.
Il semble donc bien qu'ils aient ajouté des bidouilles lors des connexions.

J'ai accès à tout, avec SSH et sudo, mais il reste à trouver ce qu'ils font qui empêche rsync de fonctionner normalement...

ug_start_server est certainement un script UGreen exécuté après connection et avant rsync. où peut-on le trouver ?

iznobe · Le 18/07/2025, à 17:47

un debut de piste , serait de verifier les groupes dont tu fais parti sur le serveur ainsi que ce que tu es comme utilisateur . il semblerait que tu sois un utilisateur " root " et pas un utilisateur " standard " avec droits sudo ( pure supposition de ma part ) parceque je vois :

login group is admin, set euid as root
cannot set euid as root

tu peux connaitre la version de debian utilisée avec :

cat /etc/os-release

ou

cat /etc/os_release

Dernière modification par iznobe (Le 18/07/2025, à 17:48)

tintinux · Le 18/07/2025, à 17:59

Ok, merci, donc :

monuser@NAS:~$ cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
OS_VERSION=1.6.0.0477

monuser est effectivement administrateur du NAS, et j'y ai accès à tout (avec sudo).
Leur interface de gestion ne donne le choix qu'entre administrateur et utilisateur normal
Un utilisateur "normal" ne peut pas se connecter en ssh .
Il y a, en effet, dans /etc/passwd :

usernormal:x:1001:100:UGREEN USER:/home/usernormal:/usr/sbin/nologin

alors que pour moi, c'est :

monuser:x:1000:10:UGREEN USER:/home/monuser:/bin/bash

Dernière modification par tintinux (Le 18/07/2025, à 18:02)

iznobe · Le 18/07/2025, à 18:11

monuser:x:1000:10:UGREEN USER:/home/monuser:/bin/bash

montre :

cat /etc/groups
groups

Je pense que tu aurais probablement beaucoup plus de chance de trouver une solution sur le forum UGREEN , ca ne doit pas etre la 1ere fois que ce genre de chose est demandée ...

Dernière modification par iznobe (Le 18/07/2025, à 18:13)

RaphaelG · Le 18/07/2025, à 22:48

Je pense que sur ton NAS UGREEN, il te manque le daemon rsync.
Même avec l'option "-e ssh", il faut quand même un rsync daemon sur la machine distante.
Sur ton NAS, tu peux le vérifier en faisant :

dpkg -l | grep rsync

Si dpkg trouve un paquet rsync, alors regarde l'état du service :

systemctl --no-pager -l status rsync.service

Mais à mon avis, le paquet rsync n'est pas présent dans ton NAS.
Comme tu affirmes, je cite "J'ai accès à tout, avec SSH et sudo", tu pourrais installer le paquet rsync qui bien entendu existe dans les dépôts Debian mais ...
- je doute que tu ais accès au super utilisateur root. Est ce que "sudo -i" fonctionne ?
- je doute que les dépôts Debian soient configurés dans /etc/apt/apt.conf.d
- le risque de casser ton NAS n'est pas négligeable.

Je te conseille plutôt :
- Depuis ton NAS, tu fais un partage NFS de /home/monuser/Documents
- Depuis ton client Ubuntu, tu fais un montage de ce partage par exemple sur /home/monuser/backup (Je sais c'est plus facile à écrire que de le réaliser)
- Du coup ta sauvegarde rsync deviendrait :
rsync -ah --delete /home/monuser/Documents/test.txt /home/monuser/backup
rsync croit que c'est en local alors que c'est un montage NFS.

IHTH.

Sciensous · Le 18/07/2025, à 23:36

est-ce que rsync est bien installé sur @serveur ?

tintinux · Le 19/07/2025, à 21:30

iznobe a écrit :

montre :
cat /etc/groups

[...]
ughomeusers:x:133:monuser,usernormal
sauvegarde:x:1000:monuser,usernormal

ughomeusers est un groupe précréé.
sauvegarde est un groupe que j'ai créé plus tard avec l'interface de gestion des utilisateurs fournie par UGreen.
Pour l'instant je n'ai utilisé que cette interface, pas de commandes directes en mode terminal.
Aucun de ces groupes ne semble avoir d'effet particulier.

tintinux · Le 19/07/2025, à 21:32

iznobe a écrit :

Je pense que tu aurais probablement beaucoup plus de chance de trouver une solution sur le forum UGREEN , ca ne doit pas etre la 1ere fois que ce genre de chose est demandée ...

Certes, mais je n'ai pas trouvé de forum UGreen.
On trouve des infos sur l'internet plus ou moins en rapport avec le souci, mais pas de solution claire.

tintinux · Le 19/07/2025, à 21:59

RaphaelG a écrit :

Je pense que sur ton NAS UGREEN, il te manque le daemon rsync.
Même avec l'option "-e ssh", il faut quand même un rsync daemon sur la machine distante.
Sur ton NAS, tu peux le vérifier en faisant :
dpkg -l | grep rsync
Si dpkg trouve un paquet rsync, alors regarde l'état du service :
systemctl --no-pager -l status rsync.service
Mais à mon avis, le paquet rsync n'est pas présent dans ton NAS.

Si, si le daemon rsync peut être activé par l'interface de gestion du système, et cela fonctionne bien ainsi.
Mais j'ai abandonné ce mode de fonctionnement de rsync qui me semble tout à fait insécurisé.
Sans mot de passe ou certificat, tout client peut obtenir la liste des modules et s'en servir pour récupérer les données sauvegardées.

RaphaelG a écrit :

Comme tu affirmes, je cite "J'ai accès à tout, avec SSH et sudo", tu pourrais installer le paquet rsync qui bien entendu existe dans les dépôts Debian mais ...
- je doute que tu ais accès au super utilisateur root. Est ce que "sudo -i" fonctionne ?
- je doute que les dépôts Debian soient configurés dans /etc/apt/apt.conf.d
- le risque de casser ton NAS n'est pas négligeable.

sudo -i marche bien, mais les dépots Debian ne sont pas configurés et à défaut UGreen ne permet d'installer qu'une liste limitée d'utilitaires avec Docker.
Tu as tout à fait raison, et je ne vais pas essayer et risquer de tout casser !

RaphaelG a écrit :

Je te conseille plutôt :
- Depuis ton NAS, tu fais un partage NFS de /home/monuser/Documents
- Depuis ton client Ubuntu, tu fais un montage de ce partage par exemple sur /home/monuser/backup (Je sais c'est plus facile à écrire que de le réaliser)
- Du coup ta sauvegarde rsync deviendrait :
rsync -ah --delete /home/monuser/Documents/test.txt /home/monuser/backup
rsync croit que c'est en local alors que c'est un montage NFS.

Oui, c'est une suggestion intéressante.
Mais quand les machines sources ne sont pas connectées à l'internet, est ce qu'elles ne risquent pas de chercher le NAS et de se ralentir ou même de se bloquer ?
C'est ce que j'avais observé autrefois... il y a peut-être moyen de l'éviter.

tintinux · Le 19/07/2025, à 22:01

Sciensous a écrit :

est-ce que rsync est bien installé sur @serveur ?

Voir réponse à RaphaelG

RaphaelG · Le 19/07/2025, à 23:39

Il y a 2 types de montage NFS : hard ou soft.
Il y a très longtemps que je n'ai pas joué avec NFS mais j'ai le souvenir de montages hard qui qui étaient très pénalisant lorsque le serveur n'était plus accessible. Le client essaye en permanence d'accéder au serveur et effectivement c'est très gourmand en ressource voire même bloquant.
Le mieux est d'utiliser des montages soft. Le client essaye mais n'insiste pas lourdement et finit par abandonner.
Mais tu n'es pas obliger de forcer le montage dans /etc/fstab. Tu peux très bien faire le montage depuis un script que tu lanceras que lorsque tu seras dans ton réseau local.
e.g.:

sudo mount -t nfs -o rw,soft serveur:/home/monuser/Documents /home/monuser/backup
# Tester que le mount a bien été fait
rsync -ah --delete /home/monuser/Documents /home/monuser/backup
sudo umount /home/monuser/backup

Dernière modification par RaphaelG (Le 20/07/2025, à 13:38)

tintinux · Le 21/07/2025, à 09:35

Bon, cela fonctionne avec un montage NFS, mais c'est beaucoup, beaucoup plus lent qu'avec une connexion ssh (de l'ordre de 10 fois)
Et l'autre inconvénient est que pour monter un disque, il faut être administrateur, ce qui ne permettra pas une sauvegarde autonome de mes utilisateurs qui n'ont pas vocation à l'être.

Je reviens donc au comportement initial, qui doit bien avoir une explication...

monuser@Hirondelle:~$ rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:/home/monuser/Documents/

Retourne une erreur, dossier inexistant, alors que le dossier existe et qu'il est (provisoirement) accessible au monde.
Cette syntaxe fonctionne parfaitement sur un serveur Ubuntu.

par contre, sur le NAS :

rsync -ah --delete  /home/monuser/Documents/ monuser@serveur:/home/Document

(j'ai bien omis /monuser dans la cible !)

fonctionne en copiant les données sur le serveur dans le dossier /home/monuser/Documents (monuser a été ajouté ?) qui est le dossier souhaité.

Quand c'est un autre utilisateur "autreuser" qui est connecté en ssh, la destination de la copie est la même que plus haut, c'est à dire /home/monuser/Documents, sans prendre en compte "autreuser" et en détruisant évidemment les données de "monuser".

J'ai remarqué aussi que si "autreuser" n'est pas administrateur sur le NAS, rsync ne peut s'exécuter.

Comment peut-on expliquer cela ?

Dernière modification par tintinux (Le 21/07/2025, à 09:38)

RaphaelG · Le 22/07/2025, à 00:43

Le problème est qu'un NAS c'est une boite noire.
L'avantage c'est que dans ton NAS Ugreen, il y a Debian et que nous les ubunteros connaissons un peu Debian.
Depuis ton NAS et son interface de gestion, vérifie que le service rsync est bien lancé.
Pour tout ce qui suit, je suppose que c'est un service de systemd. (si cela se trouve, il se lance depuis /etc/init.d à la sysVinit et tout ce qui suit est inutile)

Avec l'utilisateur monuser (pas besoin d'être root), allons voir comment systemd voit ce service : (je pars encore sur la supposition que dans le nom du service il y a rsync dedans)

~$ systemctl list-unit-files | grep rsync
rsync.service                                                             disabled        enabled
~$

Alors moi je n'ai pas ton NAS sous la main, je le fais avec mon Ubuntu 24.04. On remarque que le service rsync existe bien mais on voit qu'il est disabled.

Pour plus de détail sur ce service : (chez toi, il se pourrait bien que ce soit un truc du genre ugreen_rsync.service)

~$ systemctl --no-pager status rsync.service
○ rsync.service - fast remote file copy program daemon
     Loaded: loaded (/usr/lib/systemd/system/rsync.service; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:rsync(1)
             man:rsyncd.conf(5)
~$

Chez moi le service ne tourne pas (disabled) bien qu'à l'installation du paquet (preset) il était censé être enabled. En effet moi, je ne fais que des sauvegardes rsync en local sur un disque externe donc j'ai expressément arrêté le service avec un "systemctl disable rsync.service".
On voit le binaire qui est utilisé : /usr/lib/systemd/system/rsync.service .
Voyons voir avec quel paquet est livré ce fichier : (je pars encore sur une autre supposition : ce binaire a été empaqueté dans un .deb)

~$ dpkg -S /usr/lib/systemd/system/rsync.service
rsync: /usr/lib/systemd/system/rsync.service
~$

Ben oui, c'est le paquet rsync. (sur fedora saurait été rsync-daemon)

Voyons dans quel version il est ;

~$ dpkg -l rsync | sed 1,5d
ii  rsync          3.2.7-1ubuntu1.2 amd64        fast, versatile, remote (and local) file-copying tool
~$

J'ai vérifié, les dépots Debian de Bookworm, donnent la même version donc d'un point de vue rsync, Debian 12 Bookworm et Ubuntu 24.04 Noble devraient être compatible.

Il y a un fichier important qu'il faut consulter : /etc/rsyncd.conf
Mais je ne sais pas trop ce qu'il est censé contenir.

Je suis curieux de voir ce que ça donne sur ton Ugreen.

tintinux · Le 22/07/2025, à 07:13

Je ne veux pas utiliser le service rsync, pour les raisons que j'ai indiquées ci-dessus.

RaphaelG · Le 22/07/2025, à 13:50

Je voulais juste répondre à une interrogation de ton post #18.

tintinux a écrit :

.............
Je reviens donc au comportement initial, qui doit bien avoir une explication... ....................
monuser@Hirondelle:~$ rsync -ah --delete /home/monuser/Documents/test.txt monuser@serveur:/home/monuser/Documents/
Retourne une erreur, dossier inexistant, alors que le dossier existe et qu'il est (provisoirement) accessible au monde.
Cette syntaxe fonctionne parfaitement sur un serveur Ubuntu.
...............

Mai si ça ne t'intéresse plus alors mets [Abandon] dans le début du titre de ton fil.

Dernière modification par RaphaelG (Le 22/07/2025, à 13:52)

tintinux · Le 22/07/2025, à 14:51

RaphaelG a écrit :

Mai si ça ne t'intéresse plus alors mets [Abandon] dans le début du titre de ton fil.

Non, je confirme que je suis intéressé par une solution, avec rsync, mais pas avec un daemon sur le serveur cible.
La syntaxe indiquée au début et rappelée dans le #18 correspond bien au mode "simple" et fonctionne parfaitement vers une machine Ubuntu sans serveur.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/07/2025, à 11:17

ssh et rsync sur un NAS UGreen

#2 Le 18/07/2025, à 12:20

Re : ssh et rsync sur un NAS UGreen

#3 Le 18/07/2025, à 12:27

Re : ssh et rsync sur un NAS UGreen

#4 Le 18/07/2025, à 13:32

Re : ssh et rsync sur un NAS UGreen

#5 Le 18/07/2025, à 13:37

Re : ssh et rsync sur un NAS UGreen

#6 Le 18/07/2025, à 16:31

Re : ssh et rsync sur un NAS UGreen

#7 Le 18/07/2025, à 17:34

Re : ssh et rsync sur un NAS UGreen

#8 Le 18/07/2025, à 17:47

Re : ssh et rsync sur un NAS UGreen

#9 Le 18/07/2025, à 17:59

Re : ssh et rsync sur un NAS UGreen

#10 Le 18/07/2025, à 18:11

Re : ssh et rsync sur un NAS UGreen

#11 Le 18/07/2025, à 22:48

Re : ssh et rsync sur un NAS UGreen

#12 Le 18/07/2025, à 23:36

Re : ssh et rsync sur un NAS UGreen

#13 Le 19/07/2025, à 21:30

Re : ssh et rsync sur un NAS UGreen

#14 Le 19/07/2025, à 21:32

Re : ssh et rsync sur un NAS UGreen

#15 Le 19/07/2025, à 21:59

Re : ssh et rsync sur un NAS UGreen

#16 Le 19/07/2025, à 22:01

Re : ssh et rsync sur un NAS UGreen

#17 Le 19/07/2025, à 23:39

Re : ssh et rsync sur un NAS UGreen

#18 Le 21/07/2025, à 09:35

Re : ssh et rsync sur un NAS UGreen

#19 Le 22/07/2025, à 00:43

Re : ssh et rsync sur un NAS UGreen

#20 Le 22/07/2025, à 07:13

Re : ssh et rsync sur un NAS UGreen

#21 Le 22/07/2025, à 13:50

Re : ssh et rsync sur un NAS UGreen

#22 Le 22/07/2025, à 14:51

Re : ssh et rsync sur un NAS UGreen

Pied de page des forums