Synology DSM: rsync/ssh is working manually, but backintime refuses to use the same path

[Miq1]

I am using Ubuntu 22.04 LTS with backintime 1.2.1, so there is no --diagnostics yet. There seems to be no backport of a more recent backintime for Jammy.

I am trying to use backintime to back up to a remote folder on my NAS (Synology DS216j with version 7.1.1). While that is working with the folder mounted locally, but with issues like excess copying of files that are not changed, I cannot get the rsync/ssh variety to work.

I can manually rsync with ssh to the folder /volume1/NimbusBackup/ from the console, but setting up a backintime profile ends with this error:

sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/micha/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 micha@192.168.178.21:/volume1/NimbusBackup/ /home/micha/.local/share/backintime/mnt/D77AA3BC/mountpoint kann nicht eingebunden werden

micha@192.168.178.21:/volume1/NimbusBackup/: No such file or directory

Since I am using the exact same path when manually using rsync, I have no clue what may be wrong.

[buhtz]

Hello Michael,
Thanks for your report.

I don't understand your problem description. Can you be a bit more specific about it please.

"Synology" is a good indicator. Please check this two FAQ entries:

• How to use Synology DSM 5 with BIT over SSH
• How to use Synology DSM 6 with BIT over SSH

Best,
Christian

[Miq1]

Sorry for being unclear - I am German and my English may not be as good as I would hope for... Second I have not used Linux for many years and only recently converted from Windows to Ubuntu, so I am lacking knowledge about the nooks and crannies of course.

I sort of followed the FAQ, hence I was able to set up the Synology NAS to accept rsync requests over ssh for my user without requiring a password any more.

I proved it was working by rsync -vvv -e ssh micha@192.168.178.21:/volume1/NimbusBackup/, which gave me

opening connection using: ssh -l micha 192.168.178.21 rsync --server --sender -vvvde.LsfxCIvu . /volume1/NimbusBackup/  (10 args)
receiving file list ... 
server_sender starting pid=21203
[sender] make_file(.,*,0)
[sender] pushing local filters for /volume1/NimbusBackup/
[sender] make_file(#recycle,*,2)
[sender] make_file(backintime,*,2)
[sender] make_file(@eaDir,*,2)
[sender] popping local filters
send_file_list done
send_files starting
recv_file_name(.)
recv_file_name(#recycle)
recv_file_name(backintime)
recv_file_name(@eaDir)
received 4 names
done
recv_file_list done
get_local_name count=4 /volume1/NimbusBackup/
generator starting pid=5929
delta-transmission enabled
recv_generator(.,0)
recv_files(4) starting
drwxrwxrwx          4.096 2024/03/31 11:11:56 .
recv_generator(#recycle,1)
drwxrwxrwx          4.096 2024/01/19 20:14:22 #recycle
recv_generator(@eaDir,2)
drwxrwxrwx          4.096 2024/03/18 07:46:50 @eaDir
recv_generator(backintime,3)
drwxrwxrwx          4.096 2023/12/17 17:44:51 backintime
generate_files phase=1
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0  hash_hits=0  false_alarms=0 data=0
recv_files phase=2
recv_files finished
generate_files phase=3
generate_files finished

sent 20 bytes  received 552 bytes  381,33 bytes/sec
total size is 0  speedup is 0,00
client_run2 waiting on 5930
[generator] _exit_cleanup(code=0, file=main.c, line=1865): about to call exit(0)

That looks good to me and returned the folder names I was expecting.

The main difference to the FAQ seems to be that my backup folder is not in the home directory of my user, but in the root of the volume. As my Synology user is member of the administrators group, that was working before just fine (and still is, at least for rsync, as you saw before).

So I started to set up a config profile for backintime to use rsync via ssh in the same way, but that ended in the error message I posted in my initial post.

And so ended my understanding what is happening...

[buhtz]

Thanks for your reply. Please feel free to suggest improvements of the FAQ entries.

The error message indicates a problem with mounting. Currently I have no new idea or info I can add here. Let's wait maybe my team mates have something to add.

[Miq1]

@buhtz Thanks a lot so far! Keeping my fingers crossed... :wink

[Miq1]

There is a thread in Synology forum that seems to deal with a similar issue. The solution there is to mount the root instead of the qualified path, but I would not know how to tell backintime to not use the root directory then.

[Miq1]

And another oddity: Backintime is able to create the folder from the profile on the Synology, but in turn cannot find it obviously:

[buhtz]

See the blank space in the path?

Can you give me your rsync version please?

And I need the rsync call from the debug output, or the whole debug output.

[Miq1]

I am afraid that is the separating space between remote path and mount point only.

My PC is shut down for today, so I will have a look tomorrow only.

Thanks a lot for now!

[buhtz]

I am not familiar with using sshfs command on shell. Regarding to the error dialog and the message in it I have a further question. It complains that micha@192.168.178.21:Micha/backintime could not be found. Is that a valid name/identifier for a "directory" when using sshfs? Maybe there is somehow a slash missing in front of Micha before the :?

[Miq1]

Sorry, I was not able to power up my PC yesterday and will not be today either, so I can not answer the version question yet.

As for your last question: I am pretty sure the path ist not correct. The complete path would be /volume1/home/Micha/backintime. BackInTime itself manages to create that folder on the Synology when given Micha/backintime as path. All attempts to use the complete or any other path ended up in authority errors.

[Miq1]

I owe you the version: 1.4.1-1.

[Miq1]

You asked for my version number of backintime 😉 buhtz ***@***.***> schrieb am Do., 18. Apr. 2024, 11:14:

…

I owe you the version: 1.4.1-1. What does this mean? I don't understand. — Reply to this email directly, view it on GitHub <#1674 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGFPLXD7235JLCPGDU7FG33Y56FIPAVCNFSM6AAAAABFQIT4WKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRTGQYDIOJXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aryoda]

Hi @Miq1, please let me take over this issue from @buhtz since I have a Synology at hand and can try to diagnose this with BiT.

I suggest to switch to German here to make our communication easier and will write a summary in English finally so that other non-German users can understand the relevant parts...

[aryoda]

Ich würde als Erstes gerne ein paar Punkte abklären, könntest du diese bitte prüfen und beantworten? Vielen Dank!

1. Ist auf der Synology unter Systemsteuerung > Benutzer und Gruppe > Erweitert" unter "Benutzerbasis" die Option "Benutzer-Home-Dienst aktivieren" mit angekreuzt?
2. Ist der Synology-Benutzer "micha" Mitglied der "Administrators"-Gruppe ("Systemsteuerung > Benutzer und Gruppe", dort auf "Micha" doppelklicken und nachsehen, ob unter "Benutzergruppen" die Gruppe "Administrators" angekreuzt ist
3. Kannst du bitte einen Screenshot des Backup-Profiles anfügen (nur von dem Tab "Allgemein")?
4. Kannst du bitte in einem Terminal deines Computers versuchen, dich per SSH an der Synology anzumelden mit:
   ssh micha@192.168.178.21
   und wenn das klappt dann
   • die Benutzergruppen anzeigen lassen mit id micha und hier zeigen
   • prüfen, ob cd /volume1/NimbusBackup/ funktioniert (pwd muss den gleichen Pfad zeigen)
   • dann die SSH-Verbindung wie üblich mit "exit" wieder verlassen

Vielen Dank erst mal!

[Miq1]

Gerne auf deutsch 😄

1. Ja
2. Ja
3. Einen Teil siehst du im Eröffnungspost - reicht das? Ich kann das Profil nämlich wegen des Fehlers nicht speichern und muss jedesmal von vorne anfangen...
4. Das Verzeichnis heißt jetzt backintime (und wird derzeit über einen CIFS-Mount benutzt)

Micha@SynMahal:~$ id Micha
uid=1026(Micha) gid=100(users) groups=100(users),101(administrators),65536(sc-syncthing)

Micha@SynMahal:~$ ls
backintime
Micha@SynMahal:~$ cd backintime
Micha@SynMahal:~/backintime$ 

Micha@SynMahal:~/backintime$ pwd
/var/services/homes/Micha/backintime
Micha@SynMahal:~/backintime$ 

Das Verzeichnis ist also ein anderes?!?

[aryoda]

3. Einen Teil siehst du im Eröffnungspost - reicht das? Ich kann das Profil nämlich wegen des Fehlers nicht speichern und muss jedesmal von vorne anfangen...

Im Eröffnungspost sieht der SSH-Pfad /volume1/NimbusBackup plausibel aus (= mit / als erstem Zeichen),
im Screen Shot in diesem Post dagegen nicht. Daher meine Rückfrage.

BTW: Lt. FAQ soll man hier gar keinen Pfad eingeben (siehe Punkt 12) - der Grund ist mir unklar.

Aber bevor du die Config erneut anlegen musst, würde ich erst gerne noch andere Punkte abklären:

4. Das Verzeichnis heißt jetzt `backintime` (und wird derzeit über einen CIFS-Mount benutzt)

Wo heißt das Verzeichnis (jetzt) backintime?
a) Die Freigabe auf der NAS (unter "Systemsteuerung > Freigegebener Ordner")
b) Der Mountpunkt auf deinem Rechner?

Micha@SynMahal:~/backintime$ pwd
/var/services/homes/Micha/backintime
Micha@SynMahal:~/backintime$

Das Verzeichnis ist also ein anderes?!?

Was meinst du mit "ein anderes"? ssh loggt dich ins Home-Verzeichnis des NAS-Users ein und pwd
zeigt dir den absoluten Pfad zum akt. (NAS-internen) Verzeichnis an (/var/services/homes/Micha/backintime statt verkürzt ~/backintime).

Ich muss unbedingt wissen, wo du auf der NAS die Backups ablegen willst (ich gehe mal von dieser Backup-Richtung aus, also nicht davon, dass du Dateien von der NAS auf dem lokalen Rechner als Backup ablegen möchtest):

Wie heißt der freigebene Ordner für die Backups auf der NAS (Systemsteuerung > Freigegebener Ordner).

Wenn du mir bitte meine Fragen beantwortest, dann habe ich alle Infos, um das Szenario auf meiner NAS nachzustellen und eine Doku als Musterlösung zu schreiben...

[Miq1]

Wo heißt das Verzeichnis (jetzt) backintime?
a) Die Freigabe auf der NAS (unter "Systemsteuerung > Freigegebener Ordner")
b) Der Mountpunkt auf deinem Rechner?

a)! Ich benutze backintime derzeit im lokalen Modus, gesichert wird auf auf das NetBackup/-Verzeichnis auf dem Synology. Der Unterordner backintime wurde schon von backintime angelegt. DerMount in der fstab sieht so aus:

//192.168.178.21/NetBackup /mnt/backup-mit-nas cifs vers=2.0,uid=1000,gid=1000,auto,rw,credentials=/home/micha/.smbcredentials 0 0

Dieses lokale Backup funktioniert, nachdem ich im Python-Code von backintime die rsync-Option --executability entfernt habe und als Extraoptionen --no-owner --no-group --no-perms angegeben habe. (erstere verwirft letztere und ist standardmäßig gesetzt).

Für die ssh-Tests lege ich gerne ein neues an, bzw. macht backintime das ja selbst.

Was meinst du mit "ein anderes"? ssh loggt dich ins Home-Verzeichnis des NAS-Users ein und pwd
zeigt dir den absoluten Pfad zum akt. (NAS-internen) Verzeichnis an (/var/services/homes/Micha/backintime statt verkürzt ~/backintime).

Ich hatte die Tilde übersehen, sorry.

Ich muss unbedingt wissen, wo du auf der NAS die Backups ablegen willst (ich gehe mal von dieser Backup-Richtung aus, also nicht davon, dass du Dateien von der NAS auf dem lokalen Rechner als Backup ablegen möchtest):

Wie heißt der freigebene Ordner für die Backups auf der NAS (Systemsteuerung > Freigegebener Ordner).

Du gehst richtig - Backup vom PC auf das NAS ist gewünscht. Der Ort ist mir relativ egal, unter /homes/Micha fände ich es am logischsten.

Der Dateibaum in der File Station auf dem NAS sieht so aus (die backintime-Ordner in homeund homes/Micha sind Relikte meiner Versuche):

Die Freigegebenen Ordner sind diese:

[aryoda]

Ich scheitere ebenfalls beim Speicher-Versuch des Profils in BiT mit der Fehlermeldung (nur relevanter Auszug):

Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7]

Manuelle rsync-Versuche ohne Bit funktionieren nur, wenn ich keinen Zielpfad angebe (also nur micha@192.168.178.21 verwende, ohne den Pfad mit Doppelpunkt danach.

# ist nur ein "dry-run" - kopiert also nicht wirklich Dateien!
rsync -v -rtDHh --relative --checksum --links --no-p --no-g --no-o --info=progress2 --rsync-path /bin/rsync --no-i-r --rsh="ssh -p 22 -o IdentityFile=/home/<user>/.ssh/synology_sshuser_id_rsa" --dry-run --chmod=Du+wx /home/<user>/Documents "sshuser@192.168.178.21:./test"

Wenn ich dagegen --rsync-path /bin/rsync mit angebe (expliziter Pfad zu rsync auf der NAS), geht es in der Kommandozeile.

In der BiT-Config kann ich das auch angeben, bekomme beim Speicherversuch dann aber eine andere Fehlermeldung:

Can't write to: /home/<user>/.local/share/backintime/mnt/tmp_9_52672

Funktioniert es bei dir mit dieser Option in BiT?

Ich versuche es weiter am WE...

[Miq1]

Die rsync-Option brauche ich nicht, rsync gibt's genau einmal (/usr/bin/rsync) und das wird auch benutzt.

Allerdings:

Sieht also analog zu deinem Versuch aus. Das ist doch ein Link auf den ssh-Mount, und der Mountpoint sieht so aus:

dr-xr-xr-x 1 micha micha    0 Jan  1  1970 mountpoint

Also keine Schreibrechte. Gemountet wird

micha@192.168.178.21:./ on /home/micha/.local/share/backintime/mnt/41B896E4/mountpoint type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

• wo immer das dann auf dem NAS liegt. Wenn es dumm läuft, bedeutet "ohne Pfad" dann eben das root-Verzeichnis, und das sollte tatsächlich nicht schreibbar sein.

[Miq1]

@aryoda Konntest Du schon etwas herausfinden?

[aryoda]

Hallo @Miq1 es hat leider etwas länger gedauert als gedacht bei mir, sorry!

Ich habe den Grund gefunden, aber noch keine Lösung:

1. BiT prüft bei SSH-Profilen, ob der Pfad für das Backup-Ziel nach dem SSH-Login schon vorhanden ist und legt es ggf. an.
   Synology befindet sich nach dem ssh-Login dabei im Home-Folder des ssh-Users.
2. BiT verwendet dann sshfs (nicht ssh!!!), um den Folder lokal zu mounten für das Backup mit rsync.
   Hier wird aber das sftp-Subsystem von ssh verwendet und der sftp-Home-Folder auf der Synology ist aus unerklärlichen Gründen ein anderer (nämlich "fast" der Root-Folder der Synology, genauer: Der Root-Folder eines volumens).

Durch die unterschiedlichen "home"-Folder von 1. und 2. legt BiT zwar (wie du gut beobachtet und beschrieben hast) den Pfad per ssh an, scheitert dann aber am sshfs, da dort der Folder nicht mehr existiert.

So kannst du also das BiT-Profil nicht speichern...

Ich suche jetzt nach einer Lösung (Synology umkonfigurieren wäre am Besten, da BiT nicht erraten kann, wo der sftp-Home-Folder relativ zum ssh-Homefolder steht...).

Meine TODOS:

• 1. Prüfen, wie man als Anwender den Home-Folder von Synology SFTP ändern kann
• 2. Vergleichen, warum das bei Standard-openssh kein Problem ist (Synology verwendet eine angepasste openssh-Version)
• 3. FAQ für Synology anpassen (oder BiT-Code fixen). Notwendigkeit für aktivierten SFTP klarstellen

PS: Siehe man sshfs:

SSHFS allows you to mount a remote filesystem using SSH (more pre‐
cisely, the SFTP subsystem). Most SSH servers support and enable this
SFTP access by default

[aryoda]

OK, die ssh/sftp-Installation von Synology DSM 7 wurde customized und ich habe bei diversen Konfig-Versuchen in /etc/ssh/sshd_config keine Lösung gefunden, sftp und ssh ins gleiche Home-Verzeichnis zu bringen.

Ein genialer SO'ler hat aber eine tief versteckte Einstellung in der DSM-GUI gefunden, mit der das geht und ich habe damit BiT mit DSM 7 zum Laufen gebracht:

@Miq1 Könntest du bitte mal testen, ob du bei deinem Synology-User, den du für ssh verwendest (in meinem Beispiel sshuser, bei dir vermutlich micha), den Home-Folder wie in meinem Screenshot umkonfigurieren kannst? Dann sollte BiT funktionieren...

Control Panel > File Services > Advanced Settings > Change user root directories > Select User > Add > User or group > dein ssh-User auf der Synology > [x] User home

[Miq1]

@aryoda Klasse ! Das funktioniert tatsächlich. Ganz herzlichen Dank für Deine Hartnäckigkeit und Hilfe! 👍🏻

[Miq1]

Nebenschauplatz: beim Aufräumen auf dem NAS fiel mir auf, dass Synology die Größe des Backupordners berechnet, ohne die Links zu beachten. Dadurch entsteht eine "Größe", die ein Vielfaches der Kapazität des NAS darstellt. Bei mir werden z.B. statt ca. 108GB realer Größe (sagt rsync) dann mehr als 16TB angezeigt. Das NAS hat aber nur 1,9TB.

[aryoda]

@aryoda Klasse ! Das funktioniert tatsächlich. Ganz herzlichen Dank für Deine Hartnäckigkeit und Hilfe! 👍🏻

Sehr schön, vielen Dank für die Rückmeldung. Ich mache mich dann an demnächst daran, die TODOs abzuarbeiten (v. a. unsere FAQ zur Synology zu aktualisieren), hier eine engl. Zusammenfassung zu schreiben und dann das Ticket zu schließen (wenn du einverstanden bist).

[aryoda]

Bei mir werden z.B. statt ca. 108GB realer Größe (sagt rsync) dann mehr als 16TB angezeigt. Das NAS hat aber nur 1,9TB.

Danke für den Hinweis, ich werde das auch noch in den FAQs erwähnen...