Backup Pfad zu NAS-NFS Freigabe

[Steffen@Home]

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]

keinen 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]

Code: [Auswählen]

2017.09.07 14:49:48 2: Backup with command: tar -cf -
was bedeutet der einzelne Bindestrich ?

[Steffen@Home]

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]

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]

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]

Das NAS Regelt den NFS Zugriff.

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

[Steffen@Home]

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]

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

Kannst kontrollieren mit

Code: [Auswählen]

mount

[Wernieman]

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]

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]

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]

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]

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]

Hilft alles nix. Klappt einfach net mit autofs.

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

[Steffen@Home]

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]

Meins ist um die 50MB

[Steffen@Home]

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]

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

[Steffen@Home]

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.Synologyauto.Synology:

Code: [Auswählen]

BackupFHEM -fstype=nfs,rw,retry=0 192.168.1.120:/volume1/FHEMBackupund 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]

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]

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]

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]

wenn die Eingabe wieder bei

Code: [Auswählen]

pi@raspberrypi:rauskommt funktioniert das wohl nicht oder?

[amenomade]

Mach mal bitte

Code: [Auswählen]

cat /etc/passwd | grep fhem

[Steffen@Home]

Code: [Auswählen]

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

[Wernieman]

Du mountest mit

Code: [Auswählen]

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

Code: [Auswählen]

/BackupFHEM /etc/auto.SynologyFinde 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]

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]

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

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]

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]

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]

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]

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]

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]

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 --ghostauto.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]

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]

dann gib zubns doch mal Deine jetziege Version von:

Code: [Auswählen]

cat /etc/auto.Synology

[Steffen@Home]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Code: [Auswählen]

failed to create RPC listeners, exitingKannst 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]

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/FHEMBackupAntwort:

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]

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]

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]

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?

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.120der 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]

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

[Steffen@Home]

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