Backup Pfad zu NAS-NFS Freigabe

Steffen@Home · 07 September 2017, 15:11:14

Hallo Zusammen,

ich bin am verzweifeln, versuche jetzt seit stunden das FHEM Backup auf mein Netzlaufwerk zu schreiben....

NFS Freigabe vom Synology gemountet mit:

Code Auswählen

sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/blabla

mit dem user pi kann ich lesen und schreiben.

Aber ich bekomme es irgendwie nicht gebacken dass mein FHEM das Backup dort schreiben kann:

Code Auswählen

2017.09.07 14:49:48 2: Backup with command: tar -cf - "./backup" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > /mnt/blabla/FHEM-20170907_144948.tar.gz
sh: 1: cannot create /mnt/blabla/FHEM-20170907_144948.tar.gz: Permission denied
tar: -: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now
Backup done

Ich habe auch schon versucht den Besitzer und Gruppe des Ordners nach fhem:tty zu ändern:

Code Auswählen

drwxrwxrwx 4 fhem tty 4096 Sep 7 14:17 blabla

/mnt hat folgende Rechte:

Code Auswählen

drwxrwxrwx 4 root root 4096 Sep 7 14:18 mnt

Bei Global habe ich nur das Attribut

Code Auswählen

backupdir /mnt/blabla eingetragen.

Synology:
- Nur NFS Freigabe: siehe Anhang.
- keinen User extra erstellt und keine User&Gruppenberechtigungen vergeben: da für NFS-Freigabe anscheinend nicht nötig.

Hoffe jemand kann mir weiterhelfen ...danke

amenomade · 07 September 2017, 17:52:28

Zitatkeinen User extra erstellt und keine User&Gruppenberechtigungen vergeben: da für NFS-Freigabe anscheinend nicht nötig.

Ich glaube, das stimmt nicht ganz. Such mal ein bisschen in Google nach

Code Auswählen

mount nfs uid username

kumue · 07 September 2017, 18:16:17

Code Auswählen

2017.09.07 14:49:48 2: Backup with command: tar -cf -

was bedeutet der einzelne Bindestrich ?

Steffen@Home · 07 September 2017, 18:24:43

Ok. Das NAS Regelt den NFS Zugriff. Wie das jedoch alles funktioniert verstehe ich noch nicht 100%.
Habe jetzt bei den NFS Regeln unter Squash: Alle Benutzer zu ,,Admin" zuordnen gesetzt und nun funktioniert es!
Danke für den Hinweis!

Steffen@Home · 07 September 2017, 18:29:03

Code Auswählen

2017.09.07 18:21:13 2: Backup with command: tar -cf - "./backup" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > /mnt/blabla/FHEM-20170907_182113.tar.gz
Backup done

Was mich allerdings wundert ist dass die Datei eine Größe von 762 MB hat

Die Sicherung Heute mittag auf dem Raspi und dann per FTP auf den Rechner gesichert hatte nur 50MB !

Steffen@Home · 07 September 2017, 18:57:27

Ich werd noch verrückt

Habe jetzt versucht mit autofs einzubinden, jetzt kommt wieder permission denied. Gibts doch nicht!
Eintrag in: /etc/auto.Synology:

Code Auswählen


BackupFHEM -fstype=nfs,rw,retry=0 192.168.1.120:/volume1/FHEMBackup

Eintrag in: /etc/auto.master

Code Auswählen

/mnt/BackupFHEM /etc/auto.Synology

amenomade · 07 September 2017, 19:23:17

ZitatDas NAS Regelt den NFS Zugriff.

Zum Glück kann nicht jedes Client sagen: "ich darf"!

Steffen@Home · 08 September 2017, 11:50:21

Kann man irgendwie überprüfen ob autofs korrekt arbeitet?
Habe irgendwie das Gefühl dass dort schon was nicht passt....

Wenn ich in das Verzeichnis schaue mit

Code Auswählen

ls /mnt/BackupFHEM
dann zeigt es mir keine Dateien an. Es sollte aber mindestens 1ne zu sehen sein.
Ein Datei mit Nano zu erstellen mit dem User pi funktioniert auch nicht:permission denied.

amenomade · 08 September 2017, 13:17:28

Wenn ls nichts zeigt ist wahrscheinlich das Ding einfach nicht mounted.

Kannst kontrollieren mit

Code Auswählen

mount

Wernieman · 08 September 2017, 13:25:28

Ein reines "ls /mnt/BackupFHEM" reicht beim automounter nicht aus, da er erst beim "Zugriff" Mountet ... also mindestens noch ein "/" am Ende.

Ansonsten .. siehe Logfiles ...

Steffen@Home · 08 September 2017, 14:53:59

Hallo Wernieman,

ja sorry der Befehl hängt den "/" automatisch mit an.

Habe nun folgende Ausgabe erzeugen können...sagt mir aber nichts.

Eine auto.master.d gibt es bei mir nicht!

Code Auswählen

 sudo automount -f -v
Starting automounter version 5.0.8, master map /etc/auto.master
using kernel protocol version 5.02
lookup(dir): dir map /etc/auto.master.d missing or not readable
lookup(file): failed to read included master map dir:/etc/auto.master.d
lookup(file): failed to read included master map auto.master
mounted indirect on /mnt/BackupFHEM with timeout 300, freq 75 seconds

Steffen@Home · 08 September 2017, 15:04:13

Ich habe einfach mal in der auto.master

die Zeile mit +dir auto.master.d auskommentiert.

Code Auswählen

 sudo automount -f -v
Starting automounter version 5.0.8, master map /etc/auto.master
using kernel protocol version 5.02
lookup(file): failed to read included master map auto.master
mounted indirect on /mnt/BackupFHEM with timeout 300, freq 75 seconds

was heißt:

Code Auswählen

failed to read included master map auto.master

Steffen@Home · 08 September 2017, 15:09:37

habe jetzt auch mal das
+auto.master auskommentiert:

Code Auswählen

 sudo automount -f -v
Starting automounter version 5.0.8, master map /etc/auto.master
using kernel protocol version 5.02
mounted indirect on /mnt/BackupFHEM with timeout 300, freq 75 seconds

Meldungen sind zwar weg aber das permission denied selbst bei pi bleibt wenn ich versuche auf dem /mnt/BackupFHEM Verzeichnis eine Datei anzulegen.....

Steffen@Home · 08 September 2017, 15:34:06

Ich habe testhalber den Pfad mal nach /BackupFHEM in der auto.master geändert.

jetzt taucht die freigabe auch bei "mount" auf aber die Zugriffsrechte habe ich immer noch nicht! Aber es steht doch rw

?

Code Auswählen

 mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=469532k,nr_inodes=117383,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/etc/auto.Synology on /BackupFHEM type autofs (rw,relatime,fd=6,pgrp=9450,timeout=300,minproto=5,maxproto=5,indirect)

Steffen@Home · 08 September 2017, 17:54:35

Hilft alles nix. Klappt einfach net mit autofs.

Habe jetzt wieder per mount eingebunden und gut. Krampf da.

Steffen@Home · 08 September 2017, 18:19:23

Aber jetzt noch mal auf die Backup-Größe zurückzukommen.. Wieviel MB kann so eine Backup tar.gz-Datei wirklich haben?
Meine hat 762 MB

amenomade · 08 September 2017, 19:14:55

Meins ist um die 50MB

Steffen@Home · 08 September 2017, 21:26:44

Ich glaube das hängt damit zusammen dass nun auch die alten Backup-Dateien mit gesichert werden.

habe das backupdir auf "./backup" zurück geändert aber er sichert es trotzdem immer noch mit

Irgend was passt da noch nicht..wieso steht im Log ././backup ?

Code Auswählen

Backup with command: tar -cf - "./backup" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > ././backup/FHEM-20170908_211930.tar.gz
tar: ./backup/FHEM-20170908_211930.tar.gz: file changed as we read it
Backup done

Wernieman · 08 September 2017, 21:44:18

wegen automounter:
Gib uns bitte mal Deine Konfig (+ die vom "manuellen" mount)

Steffen@Home · 08 September 2017, 22:08:21

Das obige nervt mich jetzt schon dass alles mitgesichtert wird! habe das Verzeichnis auch komplett gelöscht und neu angelegt aber hilft nix.
Irgendwo wird definiert sein was alles gesichert wird, aber das habe ich nicht gefunden.

bez autofs:

manuell funktioniert es mit:

Code Auswählen

sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup

auto.master:

Code Auswählen

/BackupFHEM /etc/auto.Synology
auto.Synology:

Code Auswählen

BackupFHEM -fstype=nfs,rw,retry=0 192.168.1.120:/volume1/FHEMBackup
und viele andere Varianten aber alle gleich erfolglos. Habe im Synology Forum etwas gestöbert und dort haben viele Probleme mit NFS und Berechtigungen. Manuell geht es aber bei mir gut. Nur per Auto mount nicht, es werden nicht einmal die Dateien im VZ aufgelistet.

amenomade · 08 September 2017, 23:29:52

Ich vermute Du hast ein Berechtigungsproblem auf dem NAS selbst.
Versuch mal in auto.Synology, die Optionen uid=1000,gid=1000 hinzufügen.

Steffen@Home · 09 September 2017, 10:55:58

leider selbes Ergebnis.

Code Auswählen

BackupFHEM -fstype=nfs,rw,retry=0,uid=1000,gid=1000 192.168.1.120:/volume1/FHEMBackup

mount gibt mir das zurück:

Code Auswählen

/etc/auto.Synology on /BackupFHEM type autofs (rw,relatime,fd=6,pgrp=5341,timeout=300,minproto=5,maxproto=5,indirect)

amenomade · 09 September 2017, 12:34:42

Wenn dein user fhem ein shell hat, mach

Code Auswählen

sudo su - fhem und gucke von dort aus, ob du Zugriff hast, und ob das Filesystem des NAS gemountet wird

Steffen@Home · 09 September 2017, 13:24:13

wenn die Eingabe wieder bei

Code Auswählen

pi@raspberrypi:
rauskommt funktioniert das wohl nicht oder?

amenomade · 09 September 2017, 13:33:46

Mach mal bitte

Code Auswählen

cat /etc/passwd | grep fhem

Steffen@Home · 09 September 2017, 13:47:42

Code Auswählen

pi@raspberrypi:~ $ cat /etc/passwd | grep fhem
fhem:x:999:20::/opt/fhem:/bin/false

Wernieman · 09 September 2017, 18:02:32

Du mountest mit

Code Auswählen

sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup
Hast aber in der auto.master stehen:

Code Auswählen

/BackupFHEM /etc/auto.Synology
Finde mal den Fehler ... er steht VOR dem ersten / .....

Gib uns bitte auch mal die autofs.conf ohne Kommentarzeilen:

Code Auswählen

grep -v "^#" /etc/autofs.conf

Steffen@Home · 09 September 2017, 18:19:04

die Datei /etc/autofs.conf existiert bei mir nicht.

Den Fehler verstehe ich nicht... ich mounte manuell in das mnt Verzeichnis
aber automount soll nach /BackupFHEM mounten.

amenomade · 09 September 2017, 18:23:44

Zitatauto.master:
Code: [Auswählen]

/BackupFHEM /etc/auto.Synology

auto.Synology:
Code: [Auswählen]

BackupFHEM -fstype=nfs,rw,retry=0 192.168.1.120:/volume1/FHEMBackup

Wird aber nach /BackupFHEM/BackupFHEM mounten. Das würdest Du sogar besser sehen, wenn Du die Option --ghost nutzen würdest... was allerdings nw. empfohlen ist.

Steffen@Home · 09 September 2017, 18:53:06

Habe die auto.master zu

Code Auswählen

BackupFHEM /etc/auto.Synology geändert.

Jetzt wird aber nichts mehr gemounted.

mount sagt:

Code Auswählen

/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=469532k,nr_inodes=117383,mode=7     55)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmod     e=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xa     ttr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatim     e,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blki     o)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,mem     ory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,de     vices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,fr     eezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,ne     t_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,time     out=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=43     7,iocharset=ascii,shortname=mixed,errors=remount-ro)

amenomade · 09 September 2017, 20:31:10

Nein.
In auto.master definiert man das Verzeichnis, wo die Freigaben gemountet werden. Das ist Pflicht, und dieses Verzeichnis wird nicht editierbar.
In auto.<type> definiert man wie die Freigabe heissen wird.

auto.master => /haupt
auto.Synology => syno #für ein Synology
ergibt /haupt/syno wenn gemountet.

Mit Option --ghost wird das Verzeichnis /haupt/syno immer da sein, auch wenn nix gemountet. Ohne diese Option existiert das Verzeichnis /haupt/syno erst wenn gemountet.

amenomade · 09 September 2017, 20:53:32

Ich bin immer noch sicher, dass das Problem aber auf dem NAS ist. Wenn Du aus fhem ein backup machst, wird dies wahrscheinlich mit user fhem angelegt. Dann muss entweder ein user fhem (mit gleichem UID) auf dem NAS Rechte kriegen, oder irgendwelches Mapping (squash) gemacht werden.

Schau mal z.B. hier: https://askubuntu.com/a/679060

rabehd · 09 September 2017, 21:40:07

Genau mit dem Thema habe ich auch rumgemacht.

Mounten ging per Hand und damit auch das Backup. Da das NAS nicht ständig läuft habe ich mich auch an autofs versucht. Erfolglos! Ich glaube dann irgendwo gelesen zu haben, dass autofs auf dem Raspberry ab

(irgendeine Version) nicht funktioniert.
Meine Lösung

Code Auswählen

system("sudo mount 192.168.abc.def:/volumex/FHEMBackup /mnt/fhem -o nolock")
Das führe ich ein paar Augenblicke vor dem Backup aus und es funktioniert.

amenomade · 09 September 2017, 22:09:16

autofs ist bei mir in Betrieb, und funktioniert.

Code Auswählen

Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

Allerdings mounte ich mein NAS (kein Synology aber geht auch in Schlafmodus wenn nicht benutzt) über ssh. Einwandfrei.

Steffen@Home · 10 September 2017, 10:36:09

Dass der manuelle mount Pfad ein anderer war, war Absicht.

Habe den Pfad nun nochmals angepasst zu /mnt

Schreibrechte nun vorhanden!
Warum es jetzt funktioniert ist mir noch ein Rätsel. Selbst mit dem Pfad /BackupFHEM/BackupFHEM hätte es doch gehen müssen.
Im Synology habe ich nichts geändert.

auto.master:

Code Auswählen

/mnt /etc/auto.Synology --ghost
auto.Synology:

Code Auswählen

BackupFHEM -fstype=nfs,rw,retry=0,uid=1000,gid=1000 192.168.1.120:/volume1/FHEMBackup

mount liegt also in /mnt/BackupFHEM
auch User fhem hat nun Schreibrechte.

Die Einstellungen im Synology:
NFS Berechtigungen:

IP: meine FHEM-Server IP
Lesen/Schreiben
Squash: Alle Benutzer zu Admin
Asyn:Ja
nicht privilegierte Ports:Ja
über Kreuz anhängen:Ja

Berechtigungen:
Lokale Benutzer:
admin:Lesen/Schreiben
alle anderen:kein Zugriff

Lokale Gruppen:
administrators: Lesen/Schreiben
alle anderen:kein Zugriff

das wichtigste aus mount:

Code Auswählen

/etc/auto.Synology on /mnt type autofs (rw,relatime,fd=6,pgrp=6203,timeout=300,minproto=5,maxproto=5,indirect)
192.168.1.120:/volume1/FHEMBackup on /mnt/BackupFHEM type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.120,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.120)

Steffen@Home · 10 Oktober 2017, 17:51:42

Mein Backup per autofs funktioniert wohl doch nicht

wenn ich ls /mnt/BackupFHEM aufrufe kommt No such file or directory.

Mir fällt jetzt nichts mehr ein

Code Auswählen

2017.10.10 17:42:13 2: Backup with command: tar -cf - "./backup" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./maria10.conf" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > /mnt/BackupFHEM/FHEM-20171010_174213.tar.gz
sh: 1: cannot create /mnt/BackupFHEM/FHEM-20171010_174213.tar.gz: Directory nonexistent
tar: -: Wrote only 4096 of 10240 bytes
tar: Error is not recoverable: exiting now
Backup done

mount spricht:

Code Auswählen

/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=469532k,nr_inodes=117383,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/etc/auto.Synology on /mnt type autofs (rw,relatime,fd=6,pgrp=749,timeout=300,minproto=5,maxproto=5,indirect)

Wernieman · 10 Oktober 2017, 19:54:59

dann gib zubns doch mal Deine jetziege Version von:

Code Auswählen

cat /etc/auto.Synology

Steffen@Home · 10 Oktober 2017, 20:16:21

aktuell 2., habe noch etwas probiert.

Code Auswählen

#BackupFHEM -rsize=32768,wsize=32768,intr,tcp,timeo=300,rw 192.168.1.120:/volume1/FHEMBackup
BackupFHEM -fstype=nfs,rw,tcp,retry=1,timeo=300,uid=1000,gid=1000 192.168.1.120:/volume1/FHEMBackup
#BackupFHEM -fstype=nfs,rw,nfd,tcp,retry=0 192.168.1.120:/volume1/FHEMBackup

Wernieman · 10 Oktober 2017, 20:21:53

Habe noch etwas "vergessen":

Code Auswählen

grep -v "^#" /etc/autofs.conf
grep -v "^#" /etc/auto.master

Die beiden "greps", damit die Kommentarzeilen nicht mitkommen

Steffen@Home · 11 Oktober 2017, 07:01:49

Hallo Wernie,

wie gesagt eine autofs.conf gibt es bei mir nicht (schlecht?)

Die auto.master ist unverändert:

Code Auswählen

/mnt /etc/auto.Synology --ghost

Wernieman · 11 Oktober 2017, 08:37:46

Lege Dir mal eine Testweise an, mit (erstmal) folgendem inhalt (ohne die grep-Zeile):

Code Auswählen

~$ grep -v "^#" /etc/autofs.conf 
[ autofs ]
master_map_name = /etc/auto.master
timeout = 300
browse_mode = no
[ amd ]
dismount_interval = 300

Dann mal den Deamon autofs restarten (/etc/init.d/autofs restart oder mit systemctrl etc.)

Steffen@Home · 11 Oktober 2017, 09:52:09

Hallo Wernie,

Angelegt, restartet und hier der Log von autofs status:

Code Auswählen

● autofs.service - LSB: Automounts filesystems on demand
   Loaded: loaded (/etc/init.d/autofs)
   Active: active (running) since Wed 2017-10-11 09:39:27 CEST; 23s ago
  Process: 12551 ExecStop=/etc/init.d/autofs stop (code=exited, status=0/SUCCESS)
  Process: 12589 ExecStart=/etc/init.d/autofs start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/autofs.service
           └─12596 /usr/sbin/automount --pid-file /var/run/autofs.pid

Oct 11 09:39:27 raspberrypi autofs[12589]: Starting automount....
Oct 11 09:39:27 raspberrypi systemd[1]: Started LSB: Automounts filesystems on demand.

Eine Navigation nach /mnt/BackupFHEM ist nicht möglich und wird mit "No such File or Directory" beendet.

Wernieman · 11 Oktober 2017, 10:06:39

Was steht zu der Zeit dann in den üblichen Verdächtigen? also syslog, kern,log etc.

Btw:
Las mal den Parameter "--ghost" in der synology-conf weg ....

Steffen@Home · 11 Oktober 2017, 12:16:25

Zitat von: Wernieman am 11 Oktober 2017, 10:06:39
Was steht zu der Zeit dann in den üblichen Verdächtigen? also syslog, kern,log etc.

Btw:
Las mal den Parameter "--ghost" in der synology-conf weg ....

Den Parameter werde ich mal weglassen. Der wäre aber anscheinend dafür dass der mount im VZ angezeigt wird meine ich.

Mit syslog, kern,log etc. hatte ich noch nie was am Hut...Gibts da ne Beschreibung für?
Danke.

Wernieman · 12 Oktober 2017, 08:41:29

Code Auswählen

tail /var/log/syslog

Sorry aber das sind Unix Basics ... das Logverzeichnis (/var/log) solltest Du Dir mal ansehen. Ohne diese Infos ist ein Debugging nicht möglich.

Und Doku ... siehe Netz

Steffen@Home · 12 Oktober 2017, 13:10:27

Hallo Wernie,

hab ich mir jetzt angesehen.

Was mir auffällt ist dass "mount" nicht mehr wie damals die 2. Zeile also 192.168.1.120:/volume1..... ausgibt. Nur die 1. Zeile!

Code Auswählen

/etc/auto.Synology on /mnt type autofs (rw,relatime,fd=6,pgrp=6203,timeout=300,minproto=5,maxproto=5,indirect)
192.168.1.120:/volume1/FHEMBackup on /mnt/BackupFHEM type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.120,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.120)

Ich habe das --ghost zur auto.master wieder hinzugefügt sonst taucht das Verzeichnis "BackupFHEM" gar nicht erst auf in /mnt.

Im Syslog steht jetzt folgendes:

Code Auswählen

Oct 12 06:25:04 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="393" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Oct 12 06:30:01 raspberrypi rsyslogd0: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/0 ]
Oct 12 06:30:01 raspberrypi rsyslogd-2359: action 'action 17' resumed (module 'builtin:ompipe') [try http://www.rsyslog.com/e/2359 ]
Oct 12 06:30:01 raspberrypi CRON[26462]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 07:00:01 raspberrypi CRON[26780]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 07:17:01 raspberrypi CRON[26976]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 07:30:01 raspberrypi CRON[27146]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 07:34:34 raspberrypi systemd[1]: Stopping LSB: Automounts filesystems on demand...
Oct 12 07:34:35 raspberrypi automount[12880]: umount_autofs_indirect: ask umount returned busy /mnt
Oct 12 07:34:36 raspberrypi autofs[27240]: Stopping automount....
Oct 12 07:34:36 raspberrypi systemd[1]: Starting LSB: Automounts filesystems on demand...
Oct 12 07:34:37 raspberrypi autofs[27249]: Starting automount....
Oct 12 07:34:37 raspberrypi systemd[1]: Started LSB: Automounts filesystems on demand.
Oct 12 08:00:01 raspberrypi CRON[27544]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 08:17:01 raspberrypi CRON[27737]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 08:30:01 raspberrypi CRON[27878]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 09:00:01 raspberrypi CRON[28192]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 09:17:01 raspberrypi CRON[28384]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 09:30:01 raspberrypi CRON[28519]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 10:00:01 raspberrypi CRON[28837]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 10:17:01 raspberrypi CRON[29032]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 10:30:01 raspberrypi CRON[29165]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 11:00:01 raspberrypi CRON[29476]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 11:17:01 raspberrypi CRON[29676]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 11:30:01 raspberrypi CRON[29812]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 12:00:02 raspberrypi CRON[30132]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 12:00:02 raspberrypi CRON[30135]: (pi) CMD (sudo ntpdate -s 0.de.pool.ntp.org)
Oct 12 12:00:08 raspberrypi ntpdate[30145]: adjust time server 82.100.248.10 offset -0.081869 sec
Oct 12 12:17:01 raspberrypi CRON[30339]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Oct 12 12:30:01 raspberrypi CRON[30477]: (pi) CMD (sudo /usr/local/sbin/fhem-DHTAdafruit )
Oct 12 12:53:02 raspberrypi systemd[1]: Stopping LSB: Automounts filesystems on demand...
Oct 12 12:53:02 raspberrypi autofs[30822]: Stopping automount....
Oct 12 12:53:02 raspberrypi systemd[1]: Starting LSB: Automounts filesystems on demand...
Oct 12 12:53:02 raspberrypi autofs[30831]: Starting automount....
Oct 12 12:53:02 raspberrypi systemd[1]: Started LSB: Automounts filesystems on demand.
Oct 12 12:53:49 raspberrypi rpc.statd[30870]: Version 1.2.8 starting
Oct 12 12:53:49 raspberrypi rpc.statd[30870]: Flags: TI-RPC
Oct 12 12:53:49 raspberrypi rpc.statd[30870]: failed to create RPC listeners, exiting
Oct 12 12:56:11 raspberrypi systemd[1]: Stopping LSB: Automounts filesystems on demand...
Oct 12 12:56:11 raspberrypi automount[30838]: umount_autofs_indirect: ask umount returned busy /mnt
Oct 12 12:56:13 raspberrypi autofs[30915]: Stopping automount....
Oct 12 12:56:13 raspberrypi systemd[1]: Starting LSB: Automounts filesystems on demand...
Oct 12 12:56:13 raspberrypi autofs[30924]: Starting automount....
Oct 12 12:56:13 raspberrypi systemd[1]: Started LSB: Automounts filesystems on demand.
Oct 12 12:56:41 raspberrypi rpc.statd[30955]: Version 1.2.8 starting
Oct 12 12:56:41 raspberrypi rpc.statd[30955]: Flags: TI-RPC
Oct 12 12:56:41 raspberrypi rpc.statd[30955]: failed to create RPC listeners, exiting

Wernieman · 12 Oktober 2017, 13:44:51

Code Auswählen

failed to create RPC listeners, exiting
Kannst Du es per Hand mounten?

Mir sieht es danach aus, das der rpc ein Problem hat ...

Das Du es nicht "siehst" ist ein Schönheitsfehler. Spätestens beim direkten Zugriff (bei Dir "ls /mnt/BackupFHEM) muß es erscheinen. Dafür hat "--ghost" andere Nachteile, die ich (sorry) nicht diskutieren will. Ich mag es, wenn ich es direkt per ls sehe, ob es gemountet ist oder nicht.

Steffen@Home · 12 Oktober 2017, 16:52:38

Hallo Wernie,

habe jetzt auch mal den folgenden Dienst manuell gestartet bevor ich unteres Kommando startete:

Code Auswählen

sudo /etc/init.d/rpcbind start

und manuell versucht zu mounten mit:

Code Auswählen

sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup
Antwort:

Code Auswählen

pi@raspberrypi:/ $ sudo mount 192.168.1.120:/volume1/FHEMBackup /tmp/test
mount.nfs: Connection timed out

Code Auswählen

pi@raspberrypi:/ $ tail /var/log/syslog
Oct 12 16:39:34 raspberrypi systemd[1]: Stopping LSB: Automounts filesystems on demand...
Oct 12 16:39:34 raspberrypi automount[1095]: umount_autofs_indirect: ask umount returned busy /mnt
Oct 12 16:39:36 raspberrypi autofs[1190]: Stopping automount....
Oct 12 16:39:36 raspberrypi systemd[1]: Starting LSB: Automounts filesystems on demand...
Oct 12 16:39:36 raspberrypi autofs[1200]: Starting automount....
Oct 12 16:39:36 raspberrypi systemd[1]: Started LSB: Automounts filesystems on demand.
Oct 12 16:42:38 raspberrypi automount[1207]: key "192.168.1.120:" not found in map source(s).
Oct 12 16:42:38 raspberrypi automount[1207]: key "test" not found in map source(s).
Oct 12 16:44:16 raspberrypi rpc.statd[1333]: Version 1.2.8 starting
Oct 12 16:44:16 raspberrypi rpc.statd[1333]: Flags: TI-RPC

Code Auswählen


pi@raspberrypi:/ $ showmount --exports 192.168.1.120
clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused)

Wernieman · 12 Oktober 2017, 20:45:28

Es liegt devinitif nicht am autofs, sondern an nfs.

1. Erlaubt Deine NAS wirklich von Deinem PI ein NS-Mount?
2. Welche "Rechte" hast Du bei der NAS für nfs vergeben?
3. Welche rpc-Dienste laufen denn?

Code Auswählen

ps aux | grep rpc

P.S. lies mal folgendes:
https://forum.ubuntuusers.de/topic/kein-zugriff-ueber-nfs-auf-anderes-linuxsystem/

Edit:
Und folgendes ist auch gut:
http://linux.101hacks.com/unix/rpc-port-mapper-failure/

Hattest Du mal Gegoogled?

gent · 12 Oktober 2017, 21:13:57

Zitat von: Steffen@Home am 08 September 2017, 18:19:23
Aber jetzt noch mal auf die Backup-Größe zurückzukommen.. Wieviel MB kann so eine Backup tar.gz-Datei wirklich haben?
Meine hat 762 MB

Ändert man in FHEM den Backup-Pfad, werden alle alten Backups wieder in das neue Backup geschrieben, weil das FHEM Backup-Verzeichnis (das alte) in das Backup mit aufnimmt.

Schau Dir mal den Backup Befehl in FHEM vor der Änderung des Backup Verzeichnisses und danach an. Daher kommt die immense Größe.

Viele Grüße vom Gent

Steffen@Home · 13 Oktober 2017, 07:33:12

Zitat von: Wernieman am 12 Oktober 2017, 20:45:28
Es liegt devinitif nicht am autofs, sondern an nfs.

1. Erlaubt Deine NAS wirklich von Deinem PI ein NS-Mount?
2. Welche "Rechte" hast Du bei der NAS für nfs vergeben?
3. Welche rpc-Dienste laufen denn?
Code Auswählen Erweitern
ps aux | grep rpc

P.S. lies mal folgendes:
https://forum.ubuntuusers.de/topic/kein-zugriff-ueber-nfs-auf-anderes-linuxsystem/

Edit:
Und folgendes ist auch gut:
http://linux.101hacks.com/unix/rpc-port-mapper-failure/

Hattest Du mal Gegoogled?

Guten Morgen Wernie,
danke für deine Gedult

Habe jetzt deine und weitere Seiten durchforstet.

Den Erfolg brachte schließlich dass ich am NAS den NFS-Dienst Neu startete!

Danach war mit

Code Auswählen

rpcinfo -p 192.168.1.120
der portmapper wieder erreichbar

Code Auswählen

program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd
    100021    1   udp  36574  nlockmgr
    100021    3   udp  36574  nlockmgr
    100021    4   udp  36574  nlockmgr
    100021    1   tcp  50933  nlockmgr
    100021    3   tcp  50933  nlockmgr
    100021    4   tcp  50933  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100024    1   udp  50484  status
    100024    1   tcp  38857  status

Code Auswählen

showmount --exports 192.168.1.120
Export list for 192.168.1.120:
/volume1/FHEMBackup 192.168.1.123

/mnt/BackupFHEM ist jetzt wieder erreichbar mit autofs und Backup funktioniert

Bug in der DSM ?

@Gent Danke, mittlerweile habe ich das auch herausgefunden und jetzt passt das wieder (ca 50MB).

Wernieman · 13 Oktober 2017, 08:16:08

Guuute Frage .... jedenfalls war es ein Server und kein Client-Problem?

Steffen@Home · 13 Oktober 2017, 08:39:46

Gehe ich davon aus ja! Keine Ahnung warum der Dienst hängen geblieben ist. Mal beobachten.