Hallo Zusammen,
ich bin am verzweifeln, versuche jetzt seit stunden das FHEM Backup auf mein Netzlaufwerk zu schreiben....
NFS Freigabe vom Synology gemountet mit:
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:
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:
drwxrwxrwx 4 fhem tty 4096 Sep 7 14:17 blabla
/mnt hat folgende Rechte:
drwxrwxrwx 4 root root 4096 Sep 7 14:18 mnt
Bei Global habe ich nur das Attribut 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
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
mount nfs uid username
2017.09.07 14:49:48 2: Backup with command: tar -cf -
was bedeutet der einzelne Bindestrich ?
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!
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 :o
Die Sicherung Heute mittag auf dem Raspi und dann per FTP auf den Rechner gesichert hatte nur 50MB !
Ich werd noch verrückt :P
Habe jetzt versucht mit autofs einzubinden, jetzt kommt wieder permission denied. Gibts doch nicht!
Eintrag in: /etc/auto.Synology:
BackupFHEM -fstype=nfs,rw,retry=0 192.168.1.120:/volume1/FHEMBackup
Eintrag in: /etc/auto.master
/mnt/BackupFHEM /etc/auto.Synology
ZitatDas NAS Regelt den NFS Zugriff.
Zum Glück kann nicht jedes Client sagen: "ich darf"!
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
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.
Wenn ls nichts zeigt ist wahrscheinlich das Ding einfach nicht mounted.
Kannst kontrollieren mit mount
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 ...
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!
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
Ich habe einfach mal in der auto.master
die Zeile mit +dir auto.master.d auskommentiert.
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: failed to read included master map auto.master
habe jetzt auch mal das
+auto.master auskommentiert:
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.....
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 ????
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)
Hilft alles nix. Klappt einfach net mit autofs.
Habe jetzt wieder per mount eingebunden und gut. Krampf da.
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 :o
Meins ist um die 50MB
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 ?
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
wegen automounter:
Gib uns bitte mal Deine Konfig (+ die vom "manuellen" mount)
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: sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup
auto.master: /BackupFHEM /etc/auto.Synology
auto.Synology: 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.
Ich vermute Du hast ein Berechtigungsproblem auf dem NAS selbst.
Versuch mal in auto.Synology, die Optionen uid=1000,gid=1000 hinzufügen.
leider selbes Ergebnis. :(
BackupFHEM -fstype=nfs,rw,retry=0,uid=1000,gid=1000 192.168.1.120:/volume1/FHEMBackup
mount gibt mir das zurück:
/etc/auto.Synology on /BackupFHEM type autofs (rw,relatime,fd=6,pgrp=5341,timeout=300,minproto=5,maxproto=5,indirect)
Wenn dein user fhem ein shell hat, mach sudo su - fhem und gucke von dort aus, ob du Zugriff hast, und ob das Filesystem des NAS gemountet wird
wenn die Eingabe wieder bei
pi@raspberrypi:
rauskommt funktioniert das wohl nicht oder?
Mach mal bittecat /etc/passwd | grep fhem
pi@raspberrypi:~ $ cat /etc/passwd | grep fhem
fhem:x:999:20::/opt/fhem:/bin/false
Du mountest mit
sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup
Hast aber in der auto.master stehen:
/BackupFHEM /etc/auto.Synology
Finde mal den Fehler ... er steht VOR dem ersten / .....
Gib uns bitte auch mal die autofs.conf ohne Kommentarzeilen:
grep -v "^#" /etc/autofs.conf
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.
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.
Habe die auto.master zu
BackupFHEM /etc/auto.Synology geändert.
Jetzt wird aber nichts mehr gemounted.
mount sagt:
/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)
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.
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
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 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.
autofs ist bei mir in Betrieb, und funktioniert.
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.
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: /mnt /etc/auto.Synology --ghost
auto.Synology: 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:
/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)
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 ???
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:
/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)
dann gib zubns doch mal Deine jetziege Version von:
cat /etc/auto.Synology
aktuell 2., habe noch etwas probiert.
#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
Habe noch etwas "vergessen":
grep -v "^#" /etc/autofs.conf
grep -v "^#" /etc/auto.master
Die beiden "greps", damit die Kommentarzeilen nicht mitkommen
Hallo Wernie,
wie gesagt eine autofs.conf gibt es bei mir nicht (schlecht?) ???
Die auto.master ist unverändert:
/mnt /etc/auto.Synology --ghost
Lege Dir mal eine Testweise an, mit (erstmal) folgendem inhalt (ohne die grep-Zeile):
~$ 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.)
Hallo Wernie,
Angelegt, restartet und hier der Log von autofs status:
● 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.
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 ....
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.
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
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!
/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:
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
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.
Hallo Wernie,
habe jetzt auch mal den folgenden Dienst manuell gestartet bevor ich unteres Kommando startete:
sudo /etc/init.d/rpcbind start
und manuell versucht zu mounten mit:
sudo mount 192.168.1.120:/volume1/FHEMBackup /mnt/FHEMBackup
Antwort:
pi@raspberrypi:/ $ sudo mount 192.168.1.120:/volume1/FHEMBackup /tmp/test
mount.nfs: Connection timed out
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
pi@raspberrypi:/ $ showmount --exports 192.168.1.120
clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused)
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?
ps aux | grep rpc
P.S. lies mal folgendes:
https://forum.ubuntuusers.de/topic/kein-zugriff-ueber-nfs-auf-anderes-linuxsystem/ (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/ (http://linux.101hacks.com/unix/rpc-port-mapper-failure/)
Hattest Du mal Gegoogled?
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 :o
Ä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
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?
ps aux | grep rpc
P.S. lies mal folgendes:
https://forum.ubuntuusers.de/topic/kein-zugriff-ueber-nfs-auf-anderes-linuxsystem/ (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/ (http://linux.101hacks.com/unix/rpc-port-mapper-failure/)
Hattest Du mal Gegoogled?
Guten Morgen Wernie,
danke für deine Gedult ;D
Habe jetzt deine und weitere Seiten durchforstet.
Den Erfolg brachte schließlich dass ich am NAS den NFS-Dienst Neu startete!
Danach war mit
rpcinfo -p 192.168.1.120der portmapper wieder erreichbar
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
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 :o
Bug in der DSM ?
@Gent Danke, mittlerweile habe ich das auch herausgefunden und jetzt passt das wieder (ca 50MB).
Guuute Frage .... jedenfalls war es ein Server und kein Client-Problem?
Gehe ich davon aus ja! Keine Ahnung warum der Dienst hängen geblieben ist. Mal beobachten.