NFS mount Problem

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • bei rsync kannst du auch angeben, welcher Benutzer beim Ziel verwendet wird (muss dort lokal existieren).

    nachdem du das Backup generiert hast, kannst du es als root dort lokal, jedem beliebigen benutzer schenken (siehe chown).
    SW: OMV 4.1.35 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • ich habe in der /etc/ssh/sshd_config

    hab nun folgendes gefunden Root rsync

    Bei mir sieht das skript aber wie folgt aus

    Shell-Script

    1. #!/bin/bash
    2. #Private Key
    3. PRIVKEY="/volume1/ncbackup/script/synology"
    4. #Source Folder
    5. HOSTFOLDER=/var/nextcloud/backup/
    6. #Destination Folder on Synology
    7. DESTFOLDER="/volume1/ncbackup/backup"
    8. #rsync command to source server
    9. /usr/bin/rsync -avz -e "ssh -i $PRIVKEY" --rsync-path="sudo rsync" rsync@192.168.178.222:$HOSTFOLDER $DESTFOLDER
    Alles anzeigen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von daschmidt94 ()

  • #PermitRootLogin yes
    PubkeyAuthentication yes

    Gesamtes System mit root-Rechten
    Um ein vollständiges System zu sichern, sind meist root-Rechte nötig. Es ist jedoch aus Sicherheitsgründen davon abzuraten, dem Benutzer root einen direkten SSH-Zugang zu gewähren. Stattdessen legt man einen neuen Benutzer wie rsyncbenutzer an, welcher aus Sicherheitsgründen ausschließlich für rsync verwendet wird. Auch für diesen Benutzer ist die SSH-Authentifizierung in seiner noch zu erzeugenden Datei ~/.ssh/authorized_keys anzuhängen.
    Anschließend erlaubt man diesem durch die sudo-Konfiguration, mit root-Rechten ausschließlich das Programm rsync aufrufen zu dürfen. Man kann dabei auch die Passwortabfrage unterdrücken, da bereits SSH für die Authentifizierung sorgt. Es wird dazu folgendes am Ende der Datei /etc/sudoers mittels visudo eingefügt, wie im Artikel zur Konfiguration beschrieben:
    rsyncbenutzer ALL = NOPASSWD: /usr/bin/rsync Anschließend ist zu beachten, dass man nicht rsync mit sudo aufruft, sondern wie in folgendem Beispiel dessen Pfad auf sudo rsync setzt, da sudo auf dem SSH-Server und nicht dem SSH-Client aufgerufen werden muss:
    rsync --rsync-path="sudo rsync" --delete -avzbe ssh rsyncbenutzer@example.com:/ /home/benutzer/serverbackup --backup-dir=~/old hab alles so gemacht wie im wiki nur bekomme ich dann beim ausführen den fehler:

    Quellcode

    1. rsync@synology:~/.ssh$ bash /volume1/ncbackup/script/ncpbackup.sh
    2. receiving incremental file list
    3. rsync: failed to set times on "/volume1/ncbackup/backup/.": Operation not permitted (1)
    4. ./
    5. rsync: mkstemp "/volume1/ncbackup/backup/.nextcloud-bkp_20200329_03_00.tar.HWMB5h" failed: Permission denied (13)
  • ist klar, du willst dein System absichern.
    Ich habe bei mir root login erlaubt, allerdings nicht mit Passwort, sondern nur SSH key (egal von wo). das reicht mit mal als Sicherheit aus, da damit alle anderen ausgesperrt sind. Damit kann ich auch von meinem Rechner aus ohne Passwort (allerdings mit SSH key) mich mittels Putty von meinem Windows Rechner einloggen. Ist für mich sicher genug. Den SSH key halt nicht hergeben...

    ich habe im /etc/ssh/ssd_config folgendes
    PermitRootLogin yes
    PasswordAuthentication nodamit kann man sich nur noch mit SSH key einloggen.

    und nun zu deinem Problem:
    Zeig mal mit ls -la /volume1/ncbackup/backup/ dein Ziel. Irgendwas stimmt dort nicht. Und als welcher User warst du zu diesem Zeitpunkt eingeloggt?
    SW: OMV 4.1.35 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • das hier ist von der synology

    Quellcode

    1. drwxr-xr-x 2 root root 4096 Mar 29 15:07 .
    2. drwxrwxrwx+ 5 root root 4096 Mar 24 21:13 ..
    3. -rw------- 1 root root 317440 Mar 28 20:32 ncp-config_20200328.tar
    4. -rw-r--r-- 1 root root 7422689280 Mar 23 22:41 nextcloud-bkp_20200323_1584999488.tar
    5. -rw-r----- 1 root 33 43805655040 Mar 24 10:45 nextcloud-bkp_20200324_10_27.tar
    6. -rw-r----- 1 root 33 42858631971 Mar 24 22:39 nextcloud-bkp_20200324_22_18.tar.gz
    7. -rw-r----- 1 root 33 43825582080 Mar 25 03:21 nextcloud-bkp_20200325_03_00.tar
    8. -rw-r----- 1 root 33 42865102299 Mar 25 14:18 nextcloud-bkp_20200325_13_57.tar.gz
    9. -rw-r--r-- 1 root root 9135052800 Mar 27 03:04 nextcloud-bkp_20200327_03_00.tar
    10. -rw-r--r-- 1 root root 0 Mar 28 18:39 test.txt



    der hier von der Nextcloud hab jedoch schon überall mal bischen rumgespielt...



    Quellcode

    1. drwxr-xr-x 1 root root 532 Mär 29 16:14 .
    2. drwxr-xr-x 1 root root 52 Mär 24 08:02 ..
    3. -rw------- 1 root root 317440 Mär 28 20:32 ncp-config_20200328.tar
    4. -rw-r--r-- 1 root root 7422689280 Mär 23 22:41 nextcloud-bkp_20200323_1584999488.tar
    5. -rw-r----- 1 root www-data 43805655040 Mär 24 10:45 nextcloud-bkp_20200324_10_27.tar
    6. -rw-r----- 1 root www-data 42858631971 Mär 24 22:39 nextcloud-bkp_20200324_22_18.tar.gz
    7. -rw-r----- 1 root www-data 43825582080 Mär 25 03:21 nextcloud-bkp_20200325_03_00.tar
    8. -rw-r----- 1 root www-data 42865102299 Mär 25 14:18 nextcloud-bkp_20200325_13_57.tar.gz
    9. -rw-r--r-- 1 root root 9135052800 Mär 27 03:04 nextcloud-bkp_20200327_03_00.tar
    10. -rw-r----- 1 root www-data 44051916800 Mär 29 03:22 nextcloud-bkp_20200329_03_00.tar
    11. -rw-r--r-- 1 root root 0 Mär 28 18:39 test.txt
    Alles anzeigen


    ausgabe noch vom script von nextcloudpi sieht mal also das www-data besitzer ist bringts es hier etwas wenn ich meinen rsync benutzer in die www-data gruppe gebe?

    Quellcode

    1. rm "$dbbackup"
    2. chmod 640 "$destfile"
    3. chown :www-data "$destfile"
    4. echo "backup $destfile generated"
  • daschmidt94 schrieb:


    rsync --rsync-path="sudo rsync" --delete -avzbe ssh rsyncbenutzer@example.com:/ /home/benutzer/serverbackup --backup-dir=~/old hab alles so gemacht wie im wiki nur bekomme ich dann beim ausführen den fehler:

    Quellcode

    1. rsync@synology:~/.ssh$ bash /volume1/ncbackup/script/ncpbackup.sh
    2. receiving incremental file list
    3. rsync: failed to set times on "/volume1/ncbackup/backup/.": Operation not permitted (1)
    4. ./
    5. rsync: mkstemp "/volume1/ncbackup/backup/.nextcloud-bkp_20200329_03_00.tar.HWMB5h" failed: Permission denied (13)

    unter welchem User executierst du das Script? rsync kann nämlich seine temporäre Datenübertraungsdatei (auf der Synology) nicht anlegen. Auf /volume1/ncbackup/backup/ darf nämlich nur "root" schreiben, sonst niemand.
    SW: OMV 4.1.35 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804
  • Re,

    das mit Root-Login kann man machen, wäre mir aber auch zu unsicher ...

    Besser ist es, einen Benutzer "backup" anzulegen (sofern noch nicht vorhanden) und am Ende des Backupvorganges einfach die generierte Datei dem Benutzer "backup" überschreiben (chown) ... dann generiert man für "backup" eben die SSH-Keys und nutzt dann diesen Benutzer für das rsync-Script ...

    Ich würde übrigens nur "pushen", sprich das Backupscript dahingehend erweitern, das es
    a) den chown ausführt
    b) den rsync anstösst
    c) ggf. weitere "Copyjobs" anstösst (lokales Backup z.B.)

    Sc0rp
  • wtuppa schrieb:

    daschmidt94 schrieb:

    rsync --rsync-path="sudo rsync" --delete -avzbe ssh rsyncbenutzer@example.com:/ /home/benutzer/serverbackup --backup-dir=~/old hab alles so gemacht wie im wiki nur bekomme ich dann beim ausführen den fehler:

    Quellcode

    1. rsync@synology:~/.ssh$ bash /volume1/ncbackup/script/ncpbackup.sh
    2. receiving incremental file list
    3. rsync: failed to set times on "/volume1/ncbackup/backup/.": Operation not permitted (1)
    4. ./
    5. rsync: mkstemp "/volume1/ncbackup/backup/.nextcloud-bkp_20200329_03_00.tar.HWMB5h" failed: Permission denied (13)
    unter welchem User executierst du das Script? rsync kann nämlich seine temporäre Datenübertraungsdatei (auf der Synology) nicht anlegen. Auf /volume1/ncbackup/backup/ darf nämlich nur "root" schreiben, sonst niemand.




    Danke für deine Hilfe.
    Oft sieht man den Wald vor lauter Bäume nicht. bzw. wer lesen kann ist klar im Vorteil.
    Hab den Fehler immer am Server gesucht, ist jedoch leider durch die "spielerei" die Ordnerberächtigung der Synology etwas schiefgelaufen.

    Sc0rp schrieb:

    Re,

    das mit Root-Login kann man machen, wäre mir aber auch zu unsicher ...

    Besser ist es, einen Benutzer "backup" anzulegen (sofern noch nicht vorhanden) und am Ende des Backupvorganges einfach die generierte Datei dem Benutzer "backup" überschreiben (chown) ... dann generiert man für "backup" eben die SSH-Keys und nutzt dann diesen Benutzer für das rsync-Script ...

    Ich würde übrigens nur "pushen", sprich das Backupscript dahingehend erweitern, das es
    a) den chown ausführt
    b) den rsync anstösst
    c) ggf. weitere "Copyjobs" anstösst (lokales Backup z.B.)

    Sc0rp

    Hab nun Root login deaktiviert wie @wtuppa geschrieben hat.
    Mein rsync benutzer führt jedoch den Syncjob mit sudo aus, sprich er kann den "root" Ordner von der Nextcloud bearbeiten.

    So müsste ich auf der sicheren Seite sein oder?


    MFG Schmidt
  • daschmidt94 schrieb:

    wtuppa schrieb:

    Danke für deine Hilfe.
    Oft sieht man den Wald vor lauter Bäume nicht. bzw. wer lesen kann ist klar im Vorteil.
    Hab den Fehler immer am Server gesucht, ist jedoch leider durch die "spielerei" die Ordnerberächtigung der Synology etwas schiefgelaufen.

    das mit den Bäumen und dem Wald kenn ich leider aus eigener Erfahrung nur zu gut...
    und wenn man sich da einmal verlaufen hat, dann kommt man da fast nicht mehr alleine raus.
    SW: OMV 4.1.35 (Arrakis), Snapraid mit mergerfs, Minidlna
    MSI B150M ECO, Intel Pentium G4400, 16GB Kingston DDR4, SSD 250GB, 4TB Daten, 3*8TB+6TB SnapRaid (8TB Parity,3+3+2TB Parity2), FSP Aurum S 400W, Fractal Node 804