wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
ChickenLipsRfun2eat schrieb: ⇨ iptables = Firewall, nftables die moderne Alternative. Ich weiß nicht, was dein NAS da verwendet.
Ich habe die Firewall auf dem NAS unter Systemsteuerung > Sicherheit gefunden: sie ist nicht aktiviert. ChickenLipsRfun2eat schrieb: Wie greift rsync darauf zu? Über ssh?
Ich nutze rsync auf dem NAS als Daemon, laut Wiki lauscht der auf Port 873. ChickenLipsRfun2eat schrieb: Aber ich gehe mal davon aus, dass der ssh-key nun funktioniert. Also Analyse von BiT:
Woher weisst Du, wie man den debug-Modus startet? In der Ausgabe kam immer nur mein erster Test mit einem lokalen Backup aus dem Hauptprofil vor. Das Hauptprofil kann man aber nicht löschen. Also habe ich alle Einstellungen von Back In Time gelöscht (~/.config/backintime/config und ~/.local/share/backintime), neu gestartet und mit ssh konfiguriert. Die Fehlermeldung kommt wieder: | sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/a-zeller/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@192.168.178.12:/volume1/BackupTest /home/a-zeller/.local/share/backintime/mnt/FA5EECD0/mountpoint kann nicht eingebunden werden
read: Connection reset by peer
|
Das Problem ist, dass ich nach der Meldung abbrechen muss. Deshalb startet Back in Time jedes mal jungfräulich, der Debug-Aufruf bringt also nichts.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
wired2051 schrieb: Woher weisst Du, wie man den debug-Modus startet?
Kann ich dir nun nicht mehr sagen. Ich nehme mal an von der Project-Homepage.
| sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/a-zeller/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@192.168.178.12:/volume1/BackupTest /home/a-zeller/.local/share/backintime/mnt/FA5EECD0/mountpoint kann nicht eingebunden werden
|
Funktioniert die Befehlszeile denn manuell? Ansonsten kannst du auch bei sshfs das --debug verwenden. Wenn du -o idmap=user verwendest, darfst du nicht mit sudo oder pkexec arbeiten, wenn ich mich richtig erinnere. Allerdings verwendet man sshfs eh als Benutzer — ich weiß nur nicht, ob BiT das auch beherzigt. Ggf. gib einfach mal die ids mit an:
-o uid=101 -o gid=1010 (natürlich auf deine IDs anpassen)
Das Problem ist, dass ich nach der Meldung abbrechen muss. Deshalb startet Back in Time jedes mal jungfräulich, der Debug-Aufruf bringt also nichts.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
ChickenLipsRfun2eat schrieb: wired2051 schrieb: Woher weisst Du, wie man den debug-Modus startet?
Kann ich dir nun nicht mehr sagen. Ich nehme mal an von der Project-Homepage.
Ich weiss Dein geduldiges Engagement sehr zu schätzen! ChickenLipsRfun2eat schrieb: Funktioniert die Befehlszeile denn manuell? Ansonsten kannst du auch bei sshfs das --debug verwenden.
Offenbar funktioniert sie nicht (oder ich habe Dich falsch verstanden). | LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@IP_DES_NAS:/volume1/BackupTest /home/LOCAL_USER/.local/share/backintime/mnt/FA5EECD0/mountpoint
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
read: Connection reset by peer
LOCAL_USER@LOCAL_RECHNER:~$
|
Ich weiss nicht, wo ich --debug einfügen soll und habe es daher an verschiedenen Stellen versucht, die mir sinnvoll erschienen, mit und ohne -o. Das Ergebnis war immer wieder
fuse: unknown option --debug ChickenLipsRfun2eat schrieb: Wenn du -o idmap=user verwendest, darfst du nicht mit sudo oder pkexec arbeiten, wenn ich mich richtig erinnere. Allerdings verwendet man sshfs eh als Benutzer — ich weiß nur nicht, ob BiT das auch beherzigt. Ggf. gib einfach mal die ids mit an:
-o uid=101 -o gid=1010 (natürlich auf deine IDs anpassen)
Ich habe also ersteinmal UID und GID für Benutzer Backup auf dem NAS ermittelt:
| Backup@DS420:~$ id
uid=1027(Backup) gid=100(users) groups=100(users),101(administrators),65536(Backup)
|
Und dann versucht die IDs, zu verwenden: | LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa -p 22 -o uid=1027 -o gid=65536 -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@IP_DES_NAS:/volume1/BackupTest /home/LOCAL_USER/.local/share/backintime/mnt/FA5EECD0/mountpoint
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
read: Connection reset by peer
LOCAL_USER@LOCAL_RECHNER:~$
|
Das Verzeichnis /home/LOCAL_USER/.local/share/backintime/mnt/FA5EECD0/mountpoint existiert übrigens. Und die passphrase stimmt auch, denn als ich mich mal vertippt hatte, musste ich sie erneut eingeben.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
wired2051 schrieb: Ich weiss Dein geduldiges Engagement sehr zu schätzen!
Bitte 😉
Offenbar funktioniert sie nicht (oder ich habe Dich falsch verstanden). | LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa -p 22 -o idmap=user -o cache_dir_timeout=2 -o cache_stat_timeout=2 Backup@IP_DES_NAS:/volume1/BackupTest /home/LOCAL_USER/.local/share/backintime/mnt/FA5EECD0/mountpoint
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
read: Connection reset by peer
LOCAL_USER@LOCAL_RECHNER:~$
|
Ich weiss nicht, wo ich --debug einfügen soll und habe es daher an verschiedenen Stellen versucht, die mir sinnvoll erschienen, mit und ohne -o. Das Ergebnis war immer wieder
fuse: unknown option --debug
Sorry, das war mein Fehler. Ich hatte wohl noch was anderes im Kopf. sshfs hat keine --debug-Option. Debug funktionier mit -o sshfs_debug
Ich habe also ersteinmal UID und GID für Benutzer Backup auf dem NAS ermittelt:
…
Und dann versucht die IDs, zu verwenden…
Du musst die id des lokalen Nutzers angeben. Du möchtest ja die bestehenden Rechte des NAS auf deinen lokalen Benutzer mappen. Bei einem Ubuntu-Hauptbenutzer, der bei der Installation angelegt wurde, wären das uid=1000 und gid=1000.
Das Verzeichnis /home/LOCAL_USER/.local/share/backintime/mnt/FA5EECD0/mountpoint existiert übrigens. Und die passphrase stimmt auch, denn als ich mich mal vertippt hatte, musste ich sie erneut eingeben.
Gut. Also fangen wir mal von vorne an.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | ## AUF DEM NAS - als user backup
ls -lhad /volume1{,/BackupTest}
touch /volume1/BackupTest/Testdatei
## AUF DEM PC
ls -hald .local/share/backintime/mnt/FA5EECD0/mountpoint
# sshfs ohne „unnötige“ optionen
mkdir -p /tmp/sshfs_test
# Versuch 1
sshfs -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@NAS:/volume1/BackupTest /tmp/sshfs_test/
# falls das klappt:
ls -lha /tmp/sshfs_test/
fusermount -u /tmp/sshfs_test
# Versuch 2 - falls das erste nicht klappt
sshfs -o idmap=user -o uid=1000 -o gid=1000 -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@NAS:/volume1/BackupTest /tmp/sshfs_test/
|
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
...leider nein: | Backup@DS420:/volume1/BackupTest$ ls -lhad /volume1{,/BackupTest}
drwxr-xr-x 1 root root 418 Sep 3 23:36 /volume1
drwxrwxrwx+ 1 root root 22 Sep 25 15:50 /volume1/BackupTest
Backup@DS420:/volume1/BackupTest$ touch /volume1/BackupTest/Testdatei
Backup@DS420:/volume1/BackupTest$ ls -lh
total 0
drwxrwxrwx+ 1 Backup users 0 Sep 20 23:07 Daten
drwxrwxrwx+ 1 root root 8 Sep 20 10:56 @eaDir
-rwxrwxrwx+ 1 Backup users 0 Sep 28 22:55 Testdatei
Backup@DS420:/volume1/BackupTest$
|
Warum sollte ich eine Testdatei am Backup-Ziel erstellen? @eaDir wird von dem NAS erstellt z. B. für Vorschaubilder. | LOCAL_USER@LOCAL_RECHNER:~$ ls -hald .local/share/backintime/mnt/FA5EECD0/mountpoint
drwx------ 2 LOCAL_USER LOCAL_USER 4,0K Sep 25 15:46 .local/share/backintime/mnt/FA5EECD0/mountpoint
LOCAL_USER@LOCAL_RECHNER:~$ mkdir -p /tmp/sshfs_test
LOCAL_USER@LOCAL_RECHNER:~$ ls -lhad /tmp/ssh*
drwx------ 2 LOCAL_USER LOCAL_USER 4,0K Sep 28 10:54 /tmp/ssh-5BcrbUP2ilJm
drwxrwxr-x 2 LOCAL_USER LOCAL_USER 4,0K Sep 28 23:05 /tmp/sshfs_test
|
Und wieso mkdir mit -p? no error if existing, make parent directories as needed verstehe ich nicht wirklich (ich will Dich aber auch nicht übermässig beanspruchen). | LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@IP_DES_NAS:/volume1/BackupTest /tmp/sshfs_test/
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
read: Connection reset by peer
LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o idmap=user -o uid=1000 -o gid=1000 -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@IP_DES_NAS:/volume1/BackupTest /tmp/sshfs_test/
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
read: Connection reset by peer
LOCAL_USER@LOCAL_RECHNER:~$
|
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Warum sollte ich eine Testdatei am Backup-Ziel erstellen?
Na, weil da ACL wirken, die ich nicht kenne und ich wissen wollte, ob die Zugriffsrechte stimmen, also ob der Zielbenutzer aktuell noch auf das Verzeichnis lesend und schreibend zugreifen kann.
Und wieso mkdir mit -p?
Das ist eher Gewohnheit gewesen und hatte in dem speziellen Fall keine Bedeutung. Ich verwende das immer beim Anlegen mehrerer Verzeichnisebenen, weil es dann nicht so wichtig ist, welche Ebene ich schon habe. Also bspw. würde ein mkdir /home/$USER/diese/Verzeichnisse/sollen/angelegt/werden/ einen Fehler werfen, wenn es die Oberverzeichnisse nicht gibt. Mit mkdir -p würde er die nacheinander anlegen. /home/$USER/ gibt es. diese aber schon nicht. parent (Elternteil) ist immer der übergeordnete Order. Also parent von /home ist /, parent von sollen ist Verzeichnisse, etc — oder umgekehrt sind es die children (Kinder). Also child von / ist /home, aber auch /etc, usw. Zusätzlich wirft -p keinen Fehler, wenn es das anzulegende Verzeichnis schon gibt. Zurück zum Thema:
sshfs -o sshfs_debug -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@IP_DES_NAS:/volume1/BackupTest /tmp/sshfs_test/
Und dann bitte auch die Logdatei auf dem NAS untersuchen. Da sollten die SSH-Fehler auftauchen.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
Es geht voran! 😀 Eine Log-Datei konnte man mir zwar nicht nennen aber einen Hinweis-Link geben: ich hatte FTP SSL/TLS (FTPS) aktiviert, offenbar muss auch SFTP aktiviert werden. Ich verstehe die Unterschiede nicht richtig und hoffe inständig, dass Du mir jetzt nicht den Kopf abreist, weil klar war, dass SFTP aktiviert sein muss. 😲 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | LOCAL_USER@LOCAL_RECHNER:~$ ls -lhd /tmp/sshfs*
drwxrwxr-x 2 LOCAL_USER LOCAL_USER 4,0K Sep 30 15:52 /tmp/sshfs_test
LOCAL_USER@LOCAL_RECHNER:~$ sshfs -o sshfs_debug -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa backup@IP_DES_NAS:/volume1/BackupTest /tmp/sshfs_test/
SSHFS version 2.5
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
Server version: 3
Extension: posix-rename@openssh.com <1>
Extension: statvfs@openssh.com <2>
Extension: fstatvfs@openssh.com <2>
Extension: hardlink@openssh.com <1>
Extension: fsync@openssh.com <1>
Extension: lsetstat@openssh.com <1>
backup@IP_DES_NAS:/volume1/BackupTest: No such file or directory
LOCAL_USER@LOCAL_RECHNER:~$
|
Das Verzeichnis existiert und unter Berechtigungen (ACL?) hat User und Gruppe Backup vollen Zugriff (Lesen und Schreiben). | Backup@DS420:~$ ls -lh /volume1/BackupTest/
total 0
drwxrwxrwx+ 1 Backup users 0 Sep 20 23:07 Daten
drwxrwxrwx+ 1 root root 8 Sep 20 10:56 @eaDir
-rwxrwxrwx+ 1 Backup users 0 Sep 28 22:55 Testdatei
Backup@DS420:~$
|
Dann habe ich wieder Back in Time gestartet und bekam diese Meldung: Can't write to: /home/LOCAL_USER/.local/share/backintime/mnt/tmp_1_14195
Are you sure you have write access ? Ich kann tmp_1_14195 öffnen: | LOCAL_USER@LOCAL_RECHNER:~$ cd /home/LOCAL_USER/.local/share/backintime/mnt/
LOCAL_USER@LOCAL_RECHNER:~/.local/share/backintime/mnt$ ls -l
insgesamt 12
drwx------ 4 LOCAL_USER LOCAL_USER 4096 Sep 30 19:06 DB76815C
drwx------ 4 LOCAL_USER LOCAL_USER 4096 Sep 25 15:46 FA5EECD0
lrwxrwxrwx 1 LOCAL_USER LOCAL_USER 62 Sep 30 19:00 tmp_1_14195 -> /home/LOCAL_USER/.local/share/backintime/mnt/DB76815C/mountpoint
|
Hinter dem Link ist volume1 des NAS mit allen freigegebenen Ordnern verlinkt: 1
2
3
4
5
6
7
8
9
10
11
12
13 | LOCAL_USER@LOCAL_RECHNER:~/.local/share/backintime/mnt$ cd /home/LOCAL_USER/.local/share/backintime/mnt/DB76815C/mountpoint/
LOCAL_USER@LOCAL_RECHNER:~/.local/share/backintime/mnt/DB76815C/mountpoint$ ls -l
insgesamt 40
drwxrwxrwx 1 LOCAL_USER root 32 Sep 25 15:15 Backups
drwxrwxrwx 1 LOCAL_USER root 60 Sep 30 19:07 BackupTest
drwxrwxrwx 1 1027 users 72 Sep 30 19:08 home
drwxrwxrwx 1 LOCAL_USER root 50 Aug 29 17:55 homes
drwxrwxrwx 1 LOCAL_USER root 40 Sep 4 00:18 Kopien TMP
drwxrwxrwx 1 LOCAL_USER root 1660 Nov 26 2016 music
drwxrwxrwx 1 LOCAL_USER root 12 Aug 29 17:37 NetBackup
drwxrwxrwx 1 LOCAL_USER root 4350 Sep 26 21:07 photo
drwxrwxrwx 1 LOCAL_USER root 230 Sep 4 23:49 video
LOCAL_USER@LOCAL_RECHNER:~/.local/share/backintime/mnt/DB76815C/mountpoint$
|
Eigentlich sieht das jetzt doch eigentlich gut aus. Warum wird das Verzreichnis nicht gefunhden bzw. der Zugriff verweigert?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
wired2051 schrieb: …hoffe inständig, dass Du mir jetzt nicht den Kopf abreist, weil klar war, dass SFTP aktiviert sein muss. 😲
Nee, da wäre ich im Leben nicht drauf gekommen, dein Kopf braucht also nicht reisen. Aber so ist das mit Fremdsystemen. Zumindest weißt du nun, wieso wir uns hier auf Ubuntu beschränken 😉 Bei zwei Ubuntu-Rechnern reicht es völlig, wenn openssh-server installiert wird. Damit wird automatisch auch die entsprechende systemd-unit gestartet und der SSH-Dienst läuft (bei arch bspw. installierst du openssh und musst dann manuell den Server aktivieren, FreeBSD ist wieder anders,…etc.). Wie das in deinem NAS aussieht, weiß ich ja auch nicht. Ich bin zu geizig für sowas — und zugegeben auch zu faul mir die Basics da anzugucken 😇 Ich hab hier Anfang und Ende zusammengelegt, daher die Überschriften:
ACL | backup@IP_DES_NAS:/volume1/BackupTest: No such file or directory
|
… Das Verzeichnis existiert und unter Berechtigungen (ACL?) hat User und Gruppe Backup vollen Zugriff (Lesen und Schreiben).
⇨ ACL Das scheint dann auch wieder speziell zu sein. Abfragen kannst du die Rechte auf dem NAS mit | getfacl /volume1{/BackupTest}
|
Backup@DS420:~$ ls -lh /volume1/BackupTest/
total 0
drwxrwxrwx+ 1 Backup users 0 Sep 20 23:07 Daten
…
Das zeigt, dass da die ACL werkeln. Und für meinen Geschmack sind die Rechte da auch zu offen, kann aber am Konzept liegen. …Eigentlich sieht das jetzt doch eigentlich gut aus. Warum wird das Verzreichnis nicht gefunhden bzw. der Zugriff verweigert?
Ich vermute mal Folgefehler. Da müsstest du dich mal durch die ACL quälen. Bei Backups sollten die Zugriffsrechte gewahrt werden und nicht zu offen sein. tar kann bspw. keine ACL, diese muss man separat speichern (steht im Wiki-Artikel).
Zugriff testen
Hat der Nutzer Backup ein Homeverzeichnis? Da wäre es einfacher mit — root-Rechte braucht der auch keine.
| grep $USER /etc/passwd
#ergibt sowas wie
gnome:x:1009:1009::/home/gnome:/bin/bash
# ⇨ /home/gnome
|
(sollte gleich mit $HOME sein, muss aber nicht) Wenn der eins hat, nutze das für deinen Pfad. Also bspw. so | # auf dem NAS:
mkdir ~/sshfs_ordner
echo leer > ~/sshfs_ordner/editier.mich
# auf Ubuntu
ordner=/tmp/sshfs_test # egal: Der muss nur leer sein und der Nutzer die Rechte haben.
mkdir "$ordner"
sshfs -o idmap=user -o uid=$(id -u) backup@IP_DES_NAS:sshfs_ordner "$ordner"
ls -lha "$ordner"
|
Beachte: Nach dem Doppelpunkt ist kein Slash (/), da wird automatisch als Wurzelverzeichnis das Homeverzeichnis des Nutzers angenommen. Wenn das einbinden klappt, versuche die Datei editier.mich lokal zu editieren oder zu löschen, um den Schreibzugriff zu testen. Falls da nicht auch ACL werkeln, sollte das klappen. Wenn du fertig bist / aufräumen willst: | # auf Ubuntu
fusermount -u $ordner
# auf dem NAS
rm -f ~/sshfs_ordner/editier.mich
rmdir ~/sshfs_ordner
|
Den Kram in /tmp muss man ja nicht aufräumen. Das erledigt der Neustart, bzw. nach 3 Tagen systemd-tmpfiles.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
ChickenLipsRfun2eat schrieb: wired2051 schrieb: …hoffe inständig, dass Du mir jetzt nicht den Kopf abreist, weil klar war, dass SFTP aktiviert sein muss. 😲
Nee, da wäre ich im Leben nicht drauf gekommen, dein Kopf braucht also nicht reisen.
Ich dachte wohl: lieber reisen mit Rückreiseticket als dauerhaft abreissen. 😉 ChickenLipsRfun2eat schrieb: Ich bin zu geizig für sowas — und zugegeben auch zu faul mir die Basics da anzugucken 😇
Ich neige auch zum partiellen Geiz aber mein erstes NAS von 2010 war ein Quantensprung für meine Sicherheit (automatisiertes Backup) und ein schöner Spielplatz. Jetzt, mein zweites, kann Hot Swapping! Das ist ein Traum für jemanden, der/die wie ich jedes mal schwitzt, wenn er/sie an Hardware ran muss. Bis jetzt hatte ich nur Synology und bin zufrieden. /OT ChickenLipsRfun2eat schrieb: ⇨ ACL Das scheint dann auch wieder speziell zu sein. Abfragen kannst du die Rechte auf dem NAS mit | getfacl /volume1{/BackupTest}
|
Bei Synology heisst das Tool offenbar synoacltool -get aber viel Informationen habe ich dazu nicht gefunden. Aber ich habe zufällig entdeckt, dass man sich mit ls -e die ACL permissions ansehen kann. Das steht weder in der man-page noch in ACL. Richtig weiterhelfen tut mir die Ausgabe aber nicht. Ich habe mich mit ssh Backup@IP_DES_NAS eingeloggt, wobei Backup Mitglied in administrators ist und also Admin-Rechte hat. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 | Backup@DS420:~$ pwd
/var/services/homes/Backup
Backup@DS420:~$ cd /volume1/homes/Backup/
Backup@DS420:/volume1/homes/Backup$ pwd
/volume1/homes/Backup
Backup@DS420:/volume1/homes/Backup$ ls -la
total 4
drwxrwxrwx+ 1 Backup users 44 Oct 2 13:22 .
drwxrwxrwx+ 1 root root 50 Aug 29 17:55 ..
-rw------- 1 Backup users 150 Sep 30 19:08 .directory
drwxrwxrwx+ 1 root root 154 Sep 30 19:08 '#recycle'
drwxrwxrwx+ 1 Backup users 30 Sep 19 21:43 .ssh
Backup@DS420:/volume1/homes/Backup$ ls -lae
total 4
drwxrwxrwx+ 1 Backup users 44 Oct 2 13:22 .
[0] user:Backup:allow:rwxpdDaARWcCo:fd-- (level: 0)
[1] group:administrators:allow:rwxpdDaARWc--:fd-- (level: 1)
[2] owner::allow:rwxpdDaARWcCo:fdi- (level: 1)
[3] user:Backup:allow:rwxpdDaARWcCo:---- (level: 1)
[4] everyone::allow:--x----------:fd-- (level: 1)
drwxrwxrwx+ 1 root root 50 Aug 29 17:55 ..
-rw------- 1 Backup users 150 Sep 30 19:08 .directory
drwxrwxrwx+ 1 root root 154 Sep 30 19:08 '#recycle'
[0] everyone::allow:rwxpdDaARWcCo:fd-- (level: 0)
drwxrwxrwx+ 1 Backup users 30 Sep 19 21:43 .ssh
[0] user:Backup:allow:rwxpdDaARWcCo:fd-- (level: 1)
[1] group:administrators:allow:rwxpdDaARWc--:fd-- (level: 2)
[2] owner::allow:rwxpdDaARWcCo:fdi- (level: 2)
[3] user:Backup:allow:rwxpdDaARWcCo:---- (level: 2)
[4] everyone::allow:--x----------:fd-- (level: 2)
Backup@DS420:/volume1/homes/Backup$
|
Was ich auch in einem Synology Forum lass, macht mich sehr ratlos: nur Benutzer mit Admin-Rechten sollen sich mit ssh anmelden können. 😲 Kann das wirklich sein? Dann könnte ich mir user Backup sparen - aber geht das nicht zulasten der Sicherheit? tar dürfte kein Problem sein, denn ich will ein Backup haben, dass ohne spezielle Programme lesbar ist, also einen normalen Verzeichnisbaum erstellt - deshalb Back In Time. Übrigens: das volume auf dem NAS hat das Dateisystem Btrfs. ChickenLipsRfun2eat schrieb: Hat der Nutzer Backup ein Homeverzeichnis? Da wäre es einfacher mit — root-Rechte braucht der auch keine.
| grep $USER /etc/passwd
#ergibt sowas wie
gnome:x:1009:1009::/home/gnome:/bin/bash
# ⇨ /home/gnome
|
(sollte gleich mit $HOME sein, muss aber nicht)
| Backup@DS420:/volume1/homes/Backup$ grep $USER /etc/passwd
Backup:x:1027:100::/var/services/homes/Backup:/bin/sh
Backup@DS420:/volume1/homes/Backup$
|
ChickenLipsRfun2eat schrieb: Wenn der eins hat, nutze das für deinen Pfad.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | Backup@DS420:/volume1/homes/Backup$ mkdir ~/sshfs_ordner
Backup@DS420:/volume1/homes/Backup$ ls -la
total 4
drwxrwxrwx+ 1 Backup users 68 Oct 3 14:58 .
drwxrwxrwx+ 1 root root 50 Aug 29 17:55 ..
-rw------- 1 Backup users 150 Sep 30 19:08 .directory
drwxrwxrwx+ 1 root root 154 Sep 30 19:08 '#recycle'
drwxrwxrwx+ 1 Backup users 30 Sep 19 21:43 .ssh
drwxrwxrwx+ 1 Backup users 0 Oct 3 14:58 sshfs_ordner
Backup@DS420:/volume1/homes/Backup$ echo leer > ~/sshfs_ordner/editier.mich
Backup@DS420:/volume1/homes/Backup$ ls -la sshfs_ordner/
total 4
drwxrwxrwx+ 1 Backup users 24 Oct 3 14:59 .
drwxrwxrwx+ 1 Backup users 68 Oct 3 14:58 ..
-rwxrwxrwx+ 1 Backup users 5 Oct 3 14:59 editier.mich
Backup@DS420:/volume1/homes/Backup$
|
Auf dem PC bin ich dann wieder gescheitert: | LOCAL_USER@Shodan:~$ ordner=/tmp/sshfs_test
LOCAL_USER@Shodan:~$ mkdir "$ordner"
LOCAL_USER@Shodan:~$ sshfs -o idmap=user -o uid=$(id -u) backup@LOCAL_RECHNER:sshfs_ordner "$ordner"
Enter passphrase for key '/home/LOCAL_USER/.ssh/id_rsa':
backup@LOCAL_RECHNER:sshfs_ordner: No such file or directory
LOCAL_USER@Shodan:~$
|
Aber backup@LOCAL_RECHNER:sshfs_ordner existiert doch: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 | Backup@DS420:/volume1/homes/Backup$ ls -le
total 0
drwxrwxrwx+ 1 root root 154 Sep 30 19:08 '#recycle'
[0] everyone::allow:rwxpdDaARWcCo:fd-- (level: 0)
drwxrwxrwx+ 1 Backup users 24 Oct 3 14:59 sshfs_ordner
[0] user:Backup:allow:rwxpdDaARWcCo:fd-- (level: 1)
[1] group:administrators:allow:rwxpdDaARWc--:fd-- (level: 2)
[2] owner::allow:rwxpdDaARWcCo:fdi- (level: 2)
[3] user:Backup:allow:rwxpdDaARWcCo:---- (level: 2)
[4] everyone::allow:--x----------:fd-- (level: 2)
Backup@DS420:/volume1/homes/Backup$ ls -le sshfs_ordner/
total 4
-rwxrwxrwx+ 1 Backup users 5 Oct 3 14:59 editier.mich
[0] user:Backup:allow:rwxpdDaARWcCo:---- (level: 2)
[1] group:administrators:allow:rwxpdDaARWc--:---- (level: 3)
[2] user:Backup:allow:rwxpdDaARWcCo:---- (level: 3)
[3] everyone::allow:--x----------:---- (level: 3)
Backup@DS420:/volume1/homes/Backup$
|
Ich bin (immer noch) ratlos.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
So, immerhin habe ich es jetzt geschafft den Einstellungen-Dialog von Back in Time ohne Fehlermeldung zu beenden: ich habe statt den "freigegebenen Ordner" BackupTest, jetzt BackupTest unter home von User Backup auf dem NAS benutzt. Da dies rechtemässig keinen Unterschied machen sollte (User Backup hat Admin-Rechte), wundert es mich, dass ich nun weiterkomme aber was soll's. Wenn ich nun einen Schnappschuss manuell erstelle, kommt kommt zwar keine Fehlermeldung aber im rsync-Log steht: | 2021/10/14 14:19:23 [10225] building file list
2021/10/14 14:19:23 [10225] done
2021/10/14 14:19:23 [10225] rsync: mkdir "/volume1/homes/Backup/BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/new_snapshot/backup" failed: No such file or directory (2)
2021/10/14 14:19:23 [10225] rsync error: error in file IO (code 11) at main.c(689) [Receiver=3.1.2]
|
/volume1/homes/Backup/BackupTest wurde auf dem NAS erstellt (s.u.), ist aber leer. Zeile #2 in ~/.local/share/backintime/takesnapshot_.log verwirrt mich: | [I] Schnappschuss wird erstellt
[I] rsync --recursive --times --devices --specials --hard-links --human-readable --links --perms --executability --group --owner --info=progress2 --no-inc-recursive --log-file=/media/Daten/USER_DATEN/Downloads/tmp/BackInTimeQuelle/BackInTime-Test.log --rsh=ssh -o ServerAliveInterval=240 -o LogLevel=Error -o IdentityFile=/home/LOCAL_USER/.ssh/id_rsa -p 22 --delete --delete-excluded -v -i --out-format=BACKINTIME: %i %n%L --chmod=Du+wx --exclude=/home/LOCAL_USER/.local/share/backintime/mnt/1_10206 --exclude=/home/LOCAL_USER/.local/share/backintime --exclude=.local/share/backintime/mnt --include=/home/LOCAL_USER/Daten/USER_DATEN/Downloads/tmp/BackInTimeQuelle/ --include=/home/LOCAL_USER/Daten/USER_DATEN/Downloads/tmp/ --include=/home/LOCAL_USER/Daten/USER_DATEN/Downloads/ --include=/home/LOCAL_USER/Daten/USER_DATEN/ --include=/home/LOCAL_USER/Daten/ --include=/home/LOCAL_USER/ --include=/home/ --exclude=.gvfs --exclude=.cache/* --exclude=.thumbnails* --exclude=.local/share/[Tt]rash* --exclude=*.backup* --exclude=*~ --exclude=.dropbox* --exclude=/proc/* --exclude=/sys/* --exclude=/dev/* --exclude=/run/* --exclude=/etc/mtab --exclude=/var/cache/apt/archives/*.deb --exclude=lost+found/* --exclude=/tmp/* --exclude=/var/tmp/* --exclude=/var/backups/* --exclude=.Private --include=/home/LOCAL_USER/Daten/USER_DATEN/Downloads/tmp/BackInTimeQuelle/** --exclude=* / Backup@IP_DES_NAS:"BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/new_snapshot/backup"
[I] Schnappschuss erstellen (rsync: building file list ... done)
[I] Schnappschuss erstellen (rsync: rsync: mkdir "/volume1/homes/Backup/BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/new_snapshot/backup" failed: No such file or directory (2))
[E] Error: rsync: mkdir "/volume1/homes/Backup/BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/new_snapshot/backup" failed: No such file or directory (2)
[I] Schnappschuss erstellen (rsync: rsync error: error in file IO (code 11) at main.c(689) [Receiver=3.1.2])
[I] Keine Änderungen, es ist kein neuer Schnappschuss notwendig
|
/home/LOCAL_USER/Daten/USER_DATEN/Downloads/tmp/BackInTimeQuelle ist die von mir angegebnene Backup-Quelle für den Test, die übrigen includes (/home/LOCAL_USER/Daten/USER_DATEN/Downloads/tmp/ und /home/LOCAL_USER/Daten/USER_DATEN/Downloads/ usw) verwirren mich, müssen aber wohl sein. Aber warum kann /volume1/homes/Backup/BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/new_snapshot/backup nicht erstellt werden? 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | Backup@DS420:~$ ls -l
total 0
drwxrwxrwx+ 1 Backup users 0 Oct 14 14:18 BackupTest
drwxrwxrwx+ 1 root root 154 Sep 30 19:08 '#recycle'
Backup@DS420:~$ synoacltool -get BackupTest/
ACL version: 1
Archive: is_inherit,is_support_ACL
Owner: [Backup(user)]
---------------------
[0] user:Backup:allow:rwxpdDaARWcCo:fd-- (level:1)
[1] group:administrators:allow:rwxpdDaARWc--:fd-- (level:2)
[2] owner::allow:rwxpdDaARWcCo:fdi- (level:2)
[3] user:Backup:allow:rwxpdDaARWcCo:---- (level:2)
[4] everyone::allow:--x----------:fd-- (level:2)
Backup@DS420:~$
|
Wie gesagt, User Backup hat vollen Zugriff.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Ich hab das Thema voll aus den Augen verloren… Kommt vor, darfst du auch persönlich nehmen, ist es aber nicht 😉 Also was ich sehe ist, dass die Problematik jetzt auf der Synology-Seite ist und vermutlich die Schreibzugriffe von den dortigen ACL oder anderen Mechanismen blockiert werden. Da ich noch nie an so einem Gerät gesessen habe, verweigere ich dazu die Aussage — es wäre nur geraten. Ich kenne sowohl von FreeBSD, als auch von meinen „Linuxen“ nur getfacl und setfacl als Tools, also keine Ahnung was da implementiert wurde und auf welcher Basis.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
ChickenLipsRfun2eat schrieb: Ich hab das Thema voll aus den Augen verloren… Kommt vor, darfst du auch persönlich nehmen, ist es aber nicht 😉
Keine Sorge, ich weiss Deine hartnäckige Hilfsbereitschaft sehr zu schätzen, da verzeihe ich auch die ein oder andere Kaltherzigkeit. 😉 Ich denke auch, dass das ein Rechte-Problem auf dem NAS ist, nur was soll man mehr machen als Admin-Rechte geben? Egal, ich werde weiter versuchen bei Synology Hilfe zu suchen. Danke für Deine geduldige Hilfe! 👍
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Adminrechte sind nicht alles. Generell versuche ich die soweit zu vermeiden, wie es geht. Da hänge ich aber zugegeben auch noch in einer anderen Welt fest. Bei mir gibt es immer einen aktiven root-Account mit Passwort und einige Benutzer mit Aufgaben, neben den ‚menschlichen Benutzern‘. Wäre auf jeden Fall mal interessant zu erfahren, wie das bei deren System funktioniert. Hast du dasn System mittlerweile in eine unterstützte Version gebracht? Möglicherweise braucht dein NAS ja auch einfach fuse3, je nachdem wie aktuell die sind.
|
wired2051
(Themenstarter)
Anmeldungsdatum: 28. Februar 2007
Beiträge: 2740
|
ChickenLipsRfun2eat schrieb: Generell versuche ich die soweit zu vermeiden, wie es geht. Da hänge ich aber zugegeben auch noch in einer anderen Welt fest. Bei mir gibt es immer einen aktiven root-Account mit Passwort und einige Benutzer mit Aufgaben, neben den ‚menschlichen Benutzern‘.
Ich wollte/will das ja genauso machen aber ssh funktioniert offenbar nur mit admin-Rechten. 😢 Ist dieses Vorgehen inzwischen echt veraltet? Mein Kubuntu ist veraltet aber das NAS ist mit dem neuesten DSM ausgestattet... Aber ich mache auch Fortschritte: inzwischen habe ich /volume1/homes/Backup/BackupTest/backintime/LOCAL_RECHNER/LOCAL_USER/1/ auf dem NAS manuell erstellt. Nun werden auch die Unterverzeichnisse für die Snappshots angelegt - leider leer. Da das aber nun offenbar kein ssh-Problem mehr ist, habe ich ein neues Thema eröffnet: Systemverwaltung, Installation, Aktualisierung > System einrichten und verwalten > Backups > Back in Time / rsync: erstellt nur leere Verzeichnisse im Ziel. Danke für Deine Hilfe! 👍
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
wired2051 schrieb: Ich wollte/will das ja genauso machen aber ssh funktioniert offenbar nur mit admin-Rechten. 😢 Ist dieses Vorgehen inzwischen echt veraltet?
Ja. Heutzutage hat man ja in den meisten Distributionen sudo installiert, um normalen Nutzern erweiterte Rechte zu geben. Das PolicyKit unterstützt beides. Ich mag lieber eine strikte Trennung zwischen root-Aufgaben und Nutzer-Aufgaben. Mein innerer Monk hasst sudo 😉 Mein Kubuntu ist veraltet aber das NAS ist mit dem neuesten DSM ausgestattet...
Dann Neuinstallation mit 21.10. Da ist auch fuse3 mit drin. Ich würde auch die Konfiguration neu machen. Mit Plasma 5.20 kamen über tausend Änderungen rein. Und: Wozu brauchst du root-Rechte bei ssh? Da stimmt was nicht. Natürlich muss der ssh-server mit root-Rechten eingerichtet werden, aber ab dann läuft alles auf Nutzerebene.
Da das aber nun offenbar kein ssh-Problem mehr ist, habe ich ein neues Thema eröffnet…
Ich vermute nach wie vor ein Problem mit den NAS-ACL. Vielleicht kann das hier ja jemand lösen, der ein Gerät vom selben Hersteller betreibt. Mein Wissenshorizont endet da.
Danke für Deine Hilfe! 👍
Gerne 😉
|