Rsync pull vanaf synology werkt niet

[aCiDcHaOZ]

Goeiedag,

Bij een maatje aan de andere kant van NL ga ik een rPi neerleggen met een externe hardeschijf om te gebruiken als offsite backup. Ik wil graag via rsync bestanden pullen vanaf m'n synology naar m'n raspberry pi, echter blijf ik de error "permission denied" krijgen. Het vreemde is dat rsync wel werkt als ik het uitvoer vanaf m'n synology en dat scp vanaf m'n pi ook werkt. Permissies in DSM lijken ook goed te staan. Heeft iemand enig idee?

code:

ubuntu@ubuntu:~$ sudo rsync -a acidchaoz@192.168.0.199:/volume1/RaidVolume/Pub/testme/
acidchaoz@192.168.0.199's password:
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [Receiver=3.2.3]

[thunder7]

en als je

sudo ssh acidchaoz@192.168.0.199

doet, kom je dan wel binnen in de Synology? Want dat is wat rsync op de achtergrond probeert, een ssh sessie opzetten.

[aCiDcHaOZ]

Dat werkt vreemd genoeg wel!

code:

ubuntu@ubuntu:~$ sudo ssh acidchaoz@192.168.0.199
acidchaoz@192.168.0.199's password:

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

Could not chdir to home directory /var/services/homes/acidchaoz: No such file or directory
acidchaoz@FreybugServer:/$

[Merethil]

Kan het zijn dat user acidchaoz niet bij de folder

code:

/volume1/RaidVolume/Pub/testme/

mag komen?
Want dat gooit natuurlijk óók een permission denied error.

[aawe mwan]

De tool rsync kan de data ophalen via 2 verschillende protocollen: via rsync of via ssh.

Welk protocol jij wilt gebruiken, geef je op de commandline aan met de dubbele punt: een enkele dubbele punt is het ssh protocol, een dubbele dubbele punt is het rsync protocol. Zie ook man rsync .

Dus als je zegt dat je de rsync server opengezet hebt, maar op je commandline is 1 maar dubbele punt te zien voor ssh toegang, dan zit daar een mismatch.

Overigens kan je het rsync commando ook heel gemakkelijk gebruiken om op te lijsten wat er allemaal beschikbaar is op de server, zo kan je zoeken of je wel het juiste pad gebruikt! Bijvoorbeeld gewoon niets achter de dubbele punt zetten voor een lijstje van shares. Bij een rsync server heb je daarvoor niet eens een password nodig.

Je zult zien dat je niet zomaar alle systeemdirectories van de Synology kunt lezen, maar dat dit gewoon via de gedefinieerde shares (en rechten op die shares) loopt.

[ Voor 12% gewijzigd door aawe mwan op 17-12-2021 21:50 ]

[aawe mwan]

Voorbeeld van een rsync listing met ssh naar mijn ssh server die 🦘 heet:

rsync 🦘:

code:

drwxr-xr-x          4,096 2021/12/17 21:36:16 .
-rw-------            265 2021/12/17 21:36:16 .Xauthority
-rw-------          3,918 2021/12/05 23:29:07 .bash_history
-rw-r--r--            220 2020/01/21 19:11:11 .bash_logout
-rw-r--r--          4,755 2020/01/24 17:39:59 .bashrc

Voorbeeld van een rsync listing met rsync naar mijn Synology NAS waar rsync aan staat:

rsync diskstation::

code:

data            Mijn data
homes           user home
install         Installatiebestanden
Local Archiving Storage 1   System backup shared folder

[Hero of Time]

thunder7 schreef op woensdag 15 december 2021 @ 06:37:
en als je

sudo ssh acidchaoz@192.168.0.199

doet, kom je dan wel binnen in de Synology? Want dat is wat rsync op de achtergrond probeert, een ssh sessie opzetten.

Wat voor verschil ga je krijgen als je ssh als root gebruiker lokaal uitvoert om remote in te loggen? Helemaal niets.

aCiDcHaOZ schreef op woensdag 15 december 2021 @ 10:57:
Dat werkt vreemd genoeg wel!

code:

ubuntu@ubuntu:~$ sudo ssh acidchaoz@192.168.0.199
acidchaoz@192.168.0.199's password:

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

Could not chdir to home directory /var/services/homes/acidchaoz: No such file or directory
acidchaoz@FreybugServer:/$

Je hebt dus bewezen dat SSH wel werkt voor die gebruiker. Sudo en whatnot boeit in deze niet, want dat is lokaal ipv remote.

Met je rsync commando vraag ik mij ook af waar het heen moet, want je geeft alleen iets van een bron of doel op, niet beide. In dit soort gevallen moet je nagaan wat de effectieve rechten zijn en wat je commando nou precies doet. Breek het op in delen, bekijk de delen en vergelijk dan wat er anders is.

Let ook heel goed op welke rechten er gegeven wordt. Leuk dat je rsync mag uitvoeren, maar je mag nog steeds niet in /root kijken als normale gebruiker bijvoorbeeld.

[aawe mwan]

Ik denk dat ik misschien het mysterie kan oplossen.

Ik heb nog even een check gedaan door met sftp te kijken naar mijn Synology NAS (sftp is ook ssh):

code:

$ sftp uvw@diskstation
xyz@diskstation's password: 
Connected to diskstation.
sftp> cd /
sftp> dir
data      home      install   
sftp> ls -l
drwxrwxrwx   22 root     root         4096 Dec  4 08:54 data
drwxrwxrwx    7 uvw      users        4096 Apr 25  2021 home
dr-xr-xr-x   10 root     root         4096 Jun  9  2020 install
sftp>

Met sftp zie je alleen shares die je in de webinterface van de NAS gedefinieerd hebt, niet het hele filesystem.

Maar als je via ssh met een shell inlogt op de NAS (kan alleen als admin), wat jij in voorgaande berichten deed:

code:

$ ssh xyz@diskstation
xyz@diskstation's password: 
xyz@DiskStation:~$ pwd
/var/services/homes/xyz
xyz@DiskStation:~$ ls -d /volume1/@*
/volume1/@AntiVirus      /volume1/@img_mapping_table     /volume1/@SynoFinder-etc-volume
/volume1/@appstore       /volume1/@iSCSI                 /volume1/@SynoFinder-log
/volume1/@autoupdate     /volume1/@Private@              /volume1/@synologrotated.core
/volume1/@database       /volume1/@quarantine            /volume1/@syslog-ng.core
/volume1/@dms.core.gz    /volume1/@S2S                   /volume1/@syslog-ng.core.gz
/volume1/@download       /volume1/@synoavscan.core.gz    /volume1/@tmp
/volume1/@eaDir          /volume1/@synoelasticd.core     /volume1/@tmpbtdl
/volume1/@img_bkp_cache  /volume1/@SYNO.FileStatio.core  /volume1/@USBCopy
xyz@DiskStation:~$

Dan zie je dus wel het interne filesystem.
Omdat de padnamen niet hetzelfde zijn, gebruikt je dus de verkeerde padnaam in je rsync commando.

[Hero of Time]

aawe mwan schreef op zaterdag 18 december 2021 @ 14:04:
Ik denk dat ik misschien het mysterie kan oplossen.

Ik heb nog even een check gedaan door met sftp te kijken naar mijn Synology NAS (sftp is ook ssh):
[...]
Dan zie je dus wel het interne filesystem. Omdat de padnamen niet hetzelfde zijn, gebruikt je dus de verkeerde padnaam in je rsync commando.

Je verklaard niet de 'permission denied' die er terug komt. Als wat je zegt waar is, zou je 'no such file or directory' krijgen.

[aawe mwan]

Hero of Time schreef op zaterdag 18 december 2021 @ 14:13:
[...]

Je verklaard niet de 'permission denied' die er terug komt. Als wat je zegt waar is, zou je 'no such file or directory' krijgen.

Daar zit wel wat in en dat zou best kunnen.
Maar toch denk ik van niet, want als ik hier bij mij thuis dit doe:

code:

$ rsync -a acidchaoz@diskstation:/volume1/RaidVolume/Pub/testme/
acidchaoz@diskstation's password: 
Permission denied, please try again.

Als ik een willekeurig password intoets, krijg ik precies dezelfde foutmelding, terwijl op mijn NAS deze gebruikersnaam niet bestaat en deze volumenaam ook niet.

Het kan dus ook nog een username/password probleem zijn.
Nou moet je voor het rsync protocol op een apart scherm usernames en passwords invoeren, maar die werken dan alleen voor rsync via het rsync protocol en niet voor rsync via het ssh protocol. Dat kan het probleem ook nog zijn.

Hoe dan ook: zoeken naar de echte oorzaak is heel simpel met rsync nasadres::

[ Voor 3% gewijzigd door aawe mwan op 18-12-2021 14:28 ]

[aCiDcHaOZ]

Ik ben weer wat wijzer geworden, ik wist niet dat er een verschil zat in de bestandssystemen over SSH en RSYNC. Als ik het dus goed begrijp is RSYNC zowel een programma als een protocol. Via SSH wordt gaan de transfers met SFTP en als alternatief heb je het RSYNC protocol? Je hebt dus SFTP en SCP. Beide gebruiken SSH als achterliggend protocol.

Ik denk dat de verwarring bij mij zit in de beschijving van het programma RSYNC. Onderstaande tekst deed bij mij vermoeden dat RSYNC ook een protocol is.

code:

The ':' usages connect via remote shell, while '::' & 'rsync://' usages connect
to an rsync daemon, and require SRC or DEST to start with a module name.

Als ik nou username@adres:: gebruik, verbind ik dus met SFTP en met username@adres: met SCP? Let op de dubbele punten.

ik kan trouwens bevestigen dat inloggen met een niet-bestaande user en pad je dezelfde error krijgt.

code:

ubuntu@ubuntu:~$ rsync -a pindakaas@192.168.0.199:/meh/
pindakaas@192.168.0.199's password:
Permission denied, please try again.

[ Voor 34% gewijzigd door aCiDcHaOZ op 18-12-2021 23:58 ]

[Hero of Time]

@aCiDcHaOZ scp en sftp maken beide gebruik van SSH. Terwijl rsync een eigen tool is. Wat je hebt doorgestreept is juist. Rsync kan namelijk ook ssh gebruiken voor de verbinding. Iets dat veel wordt gedaan vanwege de encrypted verbinding die je krijgt alsmede dat er geen extra configuratie nodig is om rsync te laten werken. Er moet alleen rsync op beide kanten aanwezig zijn.

[aCiDcHaOZ]

Nou, het orgel draait in ieder geval en ik ben wat wijzer geworden. Iedereen bedankt voor het meedenken!

[Merethil]

aCiDcHaOZ schreef op maandag 20 december 2021 @ 04:00:
Nou, het orgel draait in ieder geval en ik ben wat wijzer geworden. Iedereen bedankt voor het meedenken!

Wat was de uiteindelijke oplossing?

[aCiDcHaOZ]

Merethil schreef op maandag 20 december 2021 @ 09:39:
[...]


Wat was de uiteindelijke oplossing?

Wel zo handig om te vermelden inderdaad ....

Ik heb alle instellingen gereset op m'n NAS. Waar net nou precies mis ging kan ik niet vertellen, de accounts waren ogenschijnlijk juist geconfigureerd en de shares ware goed ingesteld. Met het aanmaken van een nieuwe share had ik nog steeds geen toegang evenals het aanmaken van een nieuwe gebruiker. Zodoende de beslissing om weer vanaf 0 te beginnen.