Hallo!
Ich habe bisher mein Fhem Backup auf einer NAS gemacht. Nach einer Neuinstallation "jetzt Stetch" gewechselt funktioniert es nicht mehr.
Ich habe keine Ahnung mehr wie ich es damals geschafft habe. Ich habe auf der NAS einen Ordner Raspi erzeugt auf dem der User fhem alles Rechte hat. Auf dem Raspi mounte ich den Ordner mit User fhem und xxxx(Passwort). In Fhem mache ich per "at" mit "backup" jede Nacht eine Sicherung aus das NAS.
Doch leider hat fhem keine Berechtigung auf den NAS Ordner. Unter "sudo su" lassen sich Dateien zu erzeugen und löschen. Wie kann ich fhem erlauben das es auf das Verzeichnis schreiben darf.
Bitte um Hilfe. Bzw. welches Passwort hat fhem?
lg
Wolfgang
Gib uns bitte:
1. Mit welcher Technology wurde der Ordner freigegeben/eingebunden? Windows (SMB,CIFS) oder NFS?
2. Wie mountest Du? mountbefehl oder fstab-Inhalt (Bitte Passwörter XXXen)
3. Wie sehen die Berechtigungen jetzt aus (iststand, "ls -lha /backup/ordner")
Zitat von: wthiess am 14 Mai 2018, 22:31:41
Bitte um Hilfe. Bzw. welches Passwort hat fhem?
lg
Wolfgang
Nach einer Installation nach z.B. debian.fhem.de erst mal gar kein Passwort, da der dabei angelegte User fhem ein User ohne Login Shell etc. ist...
Vermutlich ist der "alte" User fhem (mit irgendeinem Passwort) nicht (mehr) der selbe wie der "neue" User fhem nach Installation (ohne Passwort)...
In Linux/Unix ist nicht (nur) der Name ausschlaggebend sondern die ID des Users...
Daher mal posten was Wernieman geschrieben hat...
Gruß, Joachim
Die fstab benötigt eine Änderung. Kam ca März 2018 mit den Debian Updates. Schau mal im Blog des tutorials. Hab den link grad nicht zur Hand. In den Kommentaren ganz unten sind zwei Varianten die gehen.
Gesendet von meinem S60 mit Tapatalk
Ich mache ein vollständiges Backup meines Systems Mittwochs und Freitags mit 5 Generationen auf dem NAS. Falls es jemanden interessiert poste ich hier mal die entsprechenden Einstellungen/Scripte:
1) Backup Verzeichnis in der /etc/fstab eintragen
//NAS/Freigabename /mnt/NAS cifs username=Benutzer,password=Passwort 0 0
2) Backup Script /usr/local/bin/backup.sh anlegen
#!/bin/bash
#
BACKUP_PATH="/mnt/NAS/Backupverzeichnis"
BACKUP_COUNT="5"
BACKUP_NAME="Backupname"
#
mount /mnt/NAS
#
systemctl stop fhem & systemctl stop mysql
#
dd if=/dev/sda of=${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
#
systemctl start mysql & systemctl start fhem
#
pushd ${BACKUP_PATH}; ls -tr ${BACKUP_PATH}/${BACKUP_NAME}* | head -n -${BACKUP_COUNT} | xargs rm; popd
In BACKUP_COUNT kann die Anzahl der Generationen angepasst werden, in SERVICES_START/STOP die Dienste die vor dem Backup gestoppt und danach wieder gestartet werden sollen (hier: FHEM und MySQL).
3) Script ausführbar machen
sudo chmod +x /usr/local/bin/backup.sh
4) Script in /etc/crontab eintragen (Sonntag und Mittwoch 3:00 Nachts)
0 3 * * 0,3 root /usr/local/bin/backup.sh #System Backup
Das Backup steht dann im Verzeichnis //NAS/Freigabename/Backupverzeichnis unter dem Namen Backupname-yyyymmtt-hhmmss.img (Datum und Uhrzeit werden ersetzt).
Die Datei kann dann Problemlos auf eine SD Karte, SSD usw. kopiert werden (mit Win32DiskImager o.Ä.) und man hat sofort wieder ein lauffähiges System. Die Sicherung einer 32GB SSD läuft bei mir ca. 3-4min.
Wenn Du es schon so automatisiert, solltest Du VOR dem dd ein "sync" machen! und am besten noch ein "kleines delay"
Trotzdem der Hinweis:
Diese kann zu einem Funktionierendem Backup führen, muß es aber nicht!
Ein Betriebsystem im laufenden Zustand sichern ist immer ein Problem, Stichwort: Geöffnete Dateien
Zitat von: Wernieman am 15 Mai 2018, 08:31:43
Diese kann zu einem Funktionierendem Backup führen, muß es aber nicht!
Deshalb stoppe ich FHEM/MySQL vorher (hab' ich oben angepasst, war noch ein Fehler drin) ... ansonsten läuft auf dem System nichts.
Wie sollte der Sync dann aussehen ?
Zitat von: Frank_Huber am 15 Mai 2018, 07:19:59
Die fstab benötigt eine Änderung. Kam ca März 2018 mit den Debian Updates. Schau mal im Blog des tutorials. Hab den link grad nicht zur Hand. In den Kommentaren ganz unten sind zwei Varianten die gehen.
Gesendet von meinem S60 mit Tapatalk
Hier die notwendige Änderung:
füge mal in Zeile 58 noch ",vers=1.0" ein.
Zeile sieht dann so aus:
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8,sec=ntlm,vers=1.0 0 0"
damit sollte es wieder gehenQuelle:
https://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/
Oder versuche mal, diesen Teil mkomplett rauszunehmen:
",sec=ntlm,vers=1.0 0 0"
Das sollte der Client eigentlich automatisch rausfinden.
und mit "sync" meine ich den Befehl "sync"
Zitat von: Wernieman am 15 Mai 2018, 09:31:29
Oder versuche mal, diesen Teil mkomplett rauszunehmen:
",sec=ntlm,vers=1.0 0 0"
Das sollte der Client eigentlich automatisch rausfinden.
Das ist die originale Zeile:
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8,sec=ntlm 0 0"Ich werde es mal testen ohne ",sec=ntlm"
Danke für den Hinweis!
Hallo,
e2image -arf /dev/sda ${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img
sollte schneller zu dem gleichen image führen.
Gruß
Eisix
dann nehme doch mal raus:
",sec=ntlm 0 0"
Zitat von: Frank_Huber am 15 Mai 2018, 07:19:59
Die fstab benötigt eine Änderung. Kam ca März 2018 mit den Debian Updates.
Betrifft die fstab Änderung nur die Raspbian/Debian Installationen oder auch Ubuntu ?
Zitat von: Eisix am 15 Mai 2018, 09:41:20
e2image -arf /dev/sda ${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img
e2image kannte ich gar nicht ... muss ich dazu unter Ubuntu noch ein Paket installieren ? sync wäre dann auch nicht nötig, wenn ich das richtig verstanden habe oder ?
Aus dem man-File:
ZitatWhen saving an e2image for debugging purposes, using either the -r or
-Q options, the filesystem must be unmounted or be mounted read/only,
in order for the image file to be in a consistent state. This require‐
ment can be overridden using the -f option, but the resulting image
file is very likely not going to be useful.
Also das gleiche Problem wie bei dd ... also ist ein "sync" vorher zu empfehlen (oder ein "richtiges" Backup)
sync bringt Linux dazu, alle Caches auf die Platte zu schreiben. So hat man ein (hoffentlich) definierten sauberen Stand auf dem Device (hier SDCard)
Zitat von: dt2510 am 15 Mai 2018, 09:55:54
Betrifft die fstab Änderung nur die Raspbian/Debian Installationen oder auch Ubuntu ?
Da ich nicht weis welches Betriebssystemupdate hierfür verantwortlich ist und ob das bei Ubuntu genauso ist kann ich es Dir leider nicht sagen.
e2image macht eigentlich das gleiche wie dd außer das der ungenutzte Bereich nicht einfach weiter kopiert wird wie bei dd, sondern wohl mit einer einzigen großen Datei gefüllt wird. Wenn mein Verständnis richtig ist. Das Image ist gleich groß und die Probleme mit sync/offenen Dateien sind die gleichen. Bei meiner halb vollen Platte ist es nur doppelt so schnell.
Bzgl Paket: bei meinem Ubuntu war es installiert. Einfach mal nachschauen.
Ansonsten --> e2image is part of the e2fsprogs package and is available from http://e2fsprogs.sourceforge.net.
Gruß
Eisix
#!/bin/bash
#
BACKUP_PATH="/mnt/NAS/Backupverzeichnis"
BACKUP_COUNT="5"
BACKUP_NAME="Backupname"
#
mount /mnt/NAS
#
systemctl stop fhem & systemctl stop mysql
#
sync
dd if=/dev/sda of=${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
#
systemctl start mysql & systemctl start fhem
#
pushd ${BACKUP_PATH}; ls -tr ${BACKUP_PATH}/${BACKUP_NAME}* | head -n -${BACKUP_COUNT} | xargs rm; popd
wäre also die sicherere Variante (oder alternativ mit e2image). Was würdest du als "richtiges" Backup empfehlen ?
Mein System ist ein standard Ubuntu Server 16.04.4 mit xfce4 (i.d.R. inaktiv), openssl, FHEM und MariaDB. FHEM und MariaDB laufen zum Zeitpunkt der Sicherung nicht mehr und es greift auch niemand von außen auf das System zu. Von daher "sollte" sich am System in dieser Zeit nichts ändern ...
Wenn alle schreibenden Dienste gestoppt sind, sollte nach normalem Ermessen ein konsistentes Image dabei herauskommen. Einen syslog kannst du hierbei vernachlässigen. Um wirklich ganz sicher zu gehen müßtest du die Disk readonly mounten und das macht ohne von extern zu booten keinen Spaß.
Ich denke so sollte es funktionieren.
Ansonsten bleiben da noch die normalen Unix backup tools (dump/ufsdump, tar,....). Bei dump hättest du auch inkrementelles Backup.
Gruß
Eisix
Mir geht es hauptsächlich darum im Falle eines Crashes möglichst schnell ein System am Laufen zu haben. Einen Dateisystemcheck kann ich dabei verschmerzen. Die für mich wichtigen Dienste (MySQL und FHEM) werden vor dem DD/e2image sauber beendet und sollten somit in sich konsistent sein.
warum mysql vorher stoppen?
Wenn genug Platz auf der Platte ist einfach einen Dump schreiben und beim kompletten Restore den Dump auch wieder zurückspielen ;-)
Die mysql Tabellen wollte ich zusätzlich noch dumpen, Platz ist genug.
Beim Einsatz von e2image bekomme ich einen Fehler:
e2image: Ungültige magische Zahl im Superblock beim Versuch, /dev/sda zu öffnen
Es kann kein gültiger Dateisystem-Superblock gefunden werden.
http://manpages.ubuntu.com/manpages/artful/man8/e2image.8.html
Du solltest nur die Partitionen /dev/sda1 usw sichern ... oder die ganze Platte im Raw Modus
Ich dachte
e2image -arf /dev/sda ${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img
sichert im RAW Modus ?
Geht (laut man Page) aber immer davon aus, das Du ein EXT-Filesystem hast.
Meine Backupstrategie sieht da etwas ander aus:
- Backup von /etc
- Backup aller wichtigen anderen Config (z.B. fhem etc)
- Backup mysql durch Dump
- Liste von installierten Programmen (Könnte man auch automatisch Ablegen)
Im Fehlerfalle wird ein Aktuelles Unix-Install-Image besorgt und eben das System neu aufgesetzt. Dann Backup der Config, DB etc. einspielen und sich freuen ...
Allerdings geht bei mir auch eine Installation schnell von statten ...
-r sicher im raw Modus, allerdings nur die Partition und nicht die ganze disk wie du es von dd her kennst.
also mußt du bei dir wahrscheinlich /dev/sda1 angeben, je nachdem wie deine Partition Table aussieht.
dd schreibt das komplette Disklayout raus und beim restore auch wieder zurück. Beim restore auf die gleiche Platte kein Problem. Beim restore auf eine kleinere Platte geht es nicht. Beim restore auf eine größer bleibt der zusätzliche Platz ungenutzt.
Gruß
Eisix
Hier noch eine Variante mit dump (details man page)
-0 bedeutet full backup, mit 1,2,3,... kann man dan inkrementelle Backups machen
-E exclude vom Backup
dump -0 -u -z -E ${BACKUP_PATH} -f ${BACKUP_PATH}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S) /
Gruß
Eisix
vielleich hilfreich, ich werfe mal das "raspiBackup" in die Runde ... https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/
verschiedene Möglichkeiten .... dd-Image, tar, ...
im DD-Mode die Möglichkeit, das Image auf nur belegten Speicherplatz zu reduzieren.
Pre- und Post-Aktionen, wie Stop Fhem, Stop MySQL, ... damit das Risiko mit offenen Files reduziert werden kann
History ... nur die xxx letzten Backups behalten, Rest löschen ...
und mehr ...
habe ich schon lange im Einsatz, Bisher konnte ich jedes Image lesen und starten.
Hallo!
Hatte leider zimlichen Stress. Ich antworte mal auf @Wernieman!
Alle anderen Strategien und Tipps sind nicht das was ich fragte. Ich benötige kein Image.
1. Meine Freigabe liegt auf einer Synologie. siehe Anhang
2. sudo nano /etc/fstab //192.168.26.220/Daten/Raspi /nas cifs username=pi,password=xxxxx,uid=pi,gid=pi 0 0
3. root@pineutal:/home/pi# ls -lha /mnt/nas
insgesamt 84K
drwxr-xr-x 2 root root 0 Mai 18 14:51 .
drwxr-xr-x 3 root root 4,0K Mai 14 21:50 ..
drwxr-xr-x 2 root root 0 Mai 18 2017 fhem
-rwxr-xr-x 1 root root 78K Apr 15 23:16 fhem.cfg
drwxr-xr-x 2 root root 0 Nov 9 2017 raspi
root@pineutal:/home/pi#
Wie schaffe ich es das Fhem auf den Ordner schreiben kann. Im Moment kann nur root schreiben. Lesen kann auch pi.
lg
Wolfgang
Zitat von: wthiess am 18 Mai 2018, 15:01:21
Wie schaffe ich es das Fhem auf den Ordner schreiben kann. Im Moment kann nur root schreiben. Lesen kann auch pi.
lg
Wolfgang
Hallo Wolfgang,
da wirst Du wohl Fhem erweiterte Rechte einräumen müssen.
PS. Falls für Dich von Interesse anbei mein Backup-Script. Das Script basiert auf dem Vorschlag von: https://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/
Denke bitte mal über folgende Parameter nach:
uid=pi,gid=pi
Und bitte
ls -lhad /mnt/nas
Man beachte das "d"
drwxr-xr-x 2 root root 0 Mai 18 14:51 /mnt/nas
ZitatHallo Wolfgang,
da wirst Du wohl Fhem erweiterte Rechte einräumen müssen.
Wie kann ich Fhem "rootrechte" geben.
Bitte keine Belehrungen über Rechte. Es ist mir wurscht. Fhem ist hinter einer Firewall und es kann niemand von außen zugreifen.
lg
Wolfgang
ZitatFhem ist hinter einer Firewall und es kann niemand von außen zugreifen.
Aber Dein Rechner hat einen Browser und ist im gleichen Netz wie Dein Pi .... nenn sich "Angriff über Bande" und ist heute Standard.
Wichtig:
Hast Du in der fstab die genannten Parameter angepasst?
Unmounte bitte mal das Device und gebe dann dem Mountpount die Richtigen Rechte:
umount /mnt/nas
chown fhem: /mnt/nas
mount -aFürs schreiben kannst DU fhem keine root-Rechte geben ....
Da komm ich nicht weiter. Mein Linuxwissen ist null.
Ich weiß nun nicht mehr was wo hingehört.
Ich werde es einfach einmal / Woche händisch sichern.
Danke für die Mühe
??? Sorry aber war das nicht Praktisch eine "Kochanleitung"?
Ich hänge mich hier mal dran.....
ZitatUnmounte bitte mal das Device und gebe dann dem Mountpount die Richtigen Rechte:
Code: [Auswählen]
umount /mnt/nas
chown fhem: /mnt/nas
mount -a
Fürs schreiben kannst DU fhem keine root-Rechte geben ....
Wenn das Verzeichnis fhem gehört dann lässt es sich doch NICHT über die fstab mounten ???
Siehe https://www.elektronik-kompendium.de/sites/raspberry-pi/2102201.htm (https://www.elektronik-kompendium.de/sites/raspberry-pi/2102201.htm)
unter Systemweites mounten.
Und warum nicht? ;o)
ich habe es im Moment wegen Zeitmangels verworfen, probiere das mal hier grob zu dokumentieren.
Auf dem NAS gibt es ein Freigabe backup, und einen Benutzer pi, selber wie auf dem Raspi mit dem selben PW, wobei dieser Benutzer ja auch NICHT mit dem oder den Benutzer auf dem Raspi gleich sein muss, so mein Verständnis. (oder?) Das NAS ist ein openmediavault.
Auf dem Raspi im /root ein Verzeichniss erstellt
drwxr-xr-x 2 root root 0 Jun 27 21:11 fhemLOG
Eingebunden über fstab
//192.168.1.95/backup /fhemLOG cifs defaults,noauto,nofail,username=pi,passwd=XXXXXXXXX,x-systemd.automount,x-systemd.requires=network-online.target 0 0
So wird es auch nach einem Neustart des Raspi eingebunden. Allerdings kann dann fhem, bzw. der Benutzer fhem darauf ja nichts schreiben.
Als ich dann probiert habe
chown fhem:dialout /fhemLOG
Wurde das Verzeichnis nicht mehr nach dem Neustart gemountet. auch ein
sudo mount -a
hat nicht mehr funktioniert.
LG
Tom
Muß jetzt gestehen, das ich mit den Parametern wenig Erfahrung habe:
Zitatx-systemd.automount,x-systemd.requires=network-online.target
Perinzipiell sollte er mounten, also mit "mount -a" es einbinden, auch wenn der Mountpoint nicht root (oder pi) gehört.
so nochmals alles auf Anfang.
Den Eintrag in der fstab aus kommentiert.
Neuen Mount Punkt erstellt:
sudo mkdir /fhem_backup_logs
Rechte zugewiesen:
sudo chown fhem:dialout /fhem_backup_logs
fstab editiert:
//192.168.1.95/backup /fhem_backup_logs cifs defaults,noauto,nofail,username=pi,passwd=XXXXXXXXXX,x-systemd.automount,x-systemd.requires=network-online.target 0 0
Neustart:
sudo reboot -n
Der Mount unkt wurde eingehängt, doch gehört er wieder root:
drwxr-xr-x 2 root root 0 Jun 27 21:11 fhem_backup_logs
Mache ich grundsätzlich etwas falsch?
LG
Tom
Mach es mal nicht unter root (/) sondern da, wo man es normalerweise macht:
/mnt/.....
Alternativ, da Du es für fhem machts, kannst Du es auch unter /op/fhem machen.
Hinweis: Wir sind unter Unix und nicht unter Windows, wo Laufwerke auf die "oberste" Ebene gehören.
hmmmm das will so nicht:
sudo mkdir /mnt/fhem_backup_logs
sudo chown fhem:dialout /mnt/fhem_backup_logs
//192.168.1.95/backup /mnt/fhem_backup_logs cifs defaults,noauto,nofail,username=pi,passwd=XXXXXXXX,x-systemd.automount,x-systemd.requires=network-online.target 0 0
sudo reboot -n
drwxr-xr-x 2 root root 0 Jul 23 11:56 fhem_backup_logs
Kann es aus Zeitgründen aktuell nicht nachbauen, aber eigentlich sollte es so funktionieren.
Kannst Du mal probieren ohne:
"x-systemd.automount,x-systemd.requires=network-online.target" und manuellen umount/mount?
Gucke erstmal, das Du es manuell hinkriegst und wenn das funzt in die automatik gehen.
@Wernieman
nicht das wir uns falsch verstehen, der Mount Punkt wird schon "verbunden" NUR ist er dann sofort dem root.
LG
Tom
Das würde nicht stören wenn fhem Schreibzugriff hat...
Gesendet von meinem Doogee S60 mit Tapatalk
Ja..... probiere es erstmal manuell zu verbinden und zu erreichen, das er eben NICHT root gehört ....
Andererseits ... könntest Du auch einfach mal die Rechte vor dem Verbinden etwas "erweitern" (chmod) .... Du willst ja erreichen, das fhem schreiben kann ...
Ansonsten einfach mal mit den mount-Parametern "spielen" .. geht aber manuell einfacher als automatisch ...
Hallo,
ich habe mir mal die Mühe gemacht und diverse Möglichkeiten der Datensicherung / Backup von FHEM aufzuschreiben und zu dokumentieren.
Vielleicht hilft Dir diese Doku weiter:
http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress_neu/?p=507 (http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress_neu/?p=507)
Viele Grüße
Jens
Hallo zusammen.
Ich habe mein System komplett neu aufgesetzt. Habe entsprechend ein Update von Raspbian auf Buster am laufen.
Vorher hat das Backup, eingerichtet nach meintechblog, ohne Probleme funktioniert.
Habe nachdem aufsetzen des Systems dann FHEM aus dem letzten Backup zurück kopiert, rechte vergben, etc. FHEM läuft soweit.
Habe jetzt aber festgestellt, dass das Backup nicht läuft.
Hat sich bei Buster etwas geändert ?
#!/bin/bash
mountIp="192.168.2.126"
mountDir="Backup"
mountUser="xxxx"
mountPass="xxxxx"
mountSubDir="FHEM"
localMountPoint="/Q/backup"
#optional
backupsMax="60"
localBackupDir="/backup"
pushoverUser="xxxxx"
pushoverToken="xxxxx"
###################################
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info backup starting now"
if [ ! -e "$localBackupDir" ]
then
echo "$localBackupDir wird erstellt"
mkdir -p "$localBackupDir"
else
echo "$localBackupDir bereits vorhanden"
fi
tar --exclude=backup -cvzf "/$localBackupDir/$(date +%y%m%d_%H%M%S)_fhem_backup.tar.gz" "/opt/fhem" &>/dev/null
if ! ping -c 1 $mountIp
then
echo "$mountIp nicht erreichbar, stop"
perl /opt/fhem/fhem.pl 7072 "set FHEM.Backup error"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info $mountIp not found"
exit
else
echo "$mountIp erreichbar"
fi
localIp=$(hostname -I|sed 's/\([0-9.]*\).*/\1/')
if [ ! -e "$localMountPoint" ]
then
echo "$localMountPoint wird erstellt"
mkdir -p "$localMountPoint"
else
echo "$localMountPoint bereits vorhanden"
fi
if [ "$(ls -A $localMountPoint)" ]
then
echo "$localMountPoint nicht leer, kein Mounten notwendig"
else
echo "$localMountPoint leer, Mounten starten"
vorhanden="0"
while read line
do
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8,sec=ntlm 0 0"
echo "mountComplete: $mountComplete"
if [ `echo "$line" | grep -c "$mountComplete"` != 0 ]
then
echo "/etc/fstab: Eintrag bereits vorhanden: $mountComplete"
vorhanden="1"
break
fi
done < "/etc/fstab"
if [ "$vorhanden" != "1" ]
then
echo "/etc/fstab: Eintrag wird ergänzt: $mountComplete"
echo "$mountComplete" >> "/etc/fstab"
fi
echo "Mounts werden aktualisiert"
mount -a
sleep 3
fi
if [ "$(ls -A $localMountPoint)" ]
then
if [ ! -e "$localMountPoint/$mountSubDir/$localIp" ]
then
mkdir -p "$localMountPoint/$mountSubDir/$localIp"
else
echo "$localMountPoint/$mountSubDir/$localIp existiert bereits"
fi
find "$localBackupDir" -name '*fhem_backup.tar.gz' | while read file
do
fileSize="0"
fileSizeMB=$(du -h $file)
fileSizeMB=${fileSizeMB%%M*}
filename=${file##*/}
echo "$filename ($fileSizeMB MB) wird in den Backupordner verschoben"
if [[ "$pushoverToken" != "" && "pushoverUser" != "" ]]
then
curl -s -F "token=$pushoverToken" -F "user=$pushoverUser" -F "title=FHEM $localIp" -F "message=Backup mit $fileSizeMB MB wird erstellt" https://api.pushover.net/1/messages.json
fi
#mv "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
cp "$file" "$localMountPoint/$mountSubDir/$localIp/$filename"
rm "$file"
perl /opt/fhem/fhem.pl 7072 "set FHEM.Backup off"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backup $filename"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupMB $fileSizeMB"
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info backup done"
done
else
echo "Mounten hat anscheinend nicht geklappt, skip."
exit
fi
#Löschen alter Backups
if [[ "$backupsMax" != "" && "$backupsMax" != "0" ]]
then
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFilesMax $backupsMax"
backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_fhem_backup.tar.gz"`
backupsDelete=$(($backupsCurrent-$backupsMax))
if [ "$backupsDelete" -gt "0" ]
then
echo "$backupsCurrent Backups vorhanden - nur $backupsMax aktuelle Backups werden vorgehalten - $backupsDelete Backups werden gelöscht"
ls -d "/$localMountPoint/$mountSubDir/$localIp/"* | grep "_fhem_backup.tar.gz" | head -$backupsDelete | xargs rm
else
echo "$backupsCurrent Backups vorhanden - bis $backupsMax aktuelle Backups werden vorgehalten"
fi
else
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFilesMax no limit"
fi
backupsCurrent=`ls -A "$localMountPoint/$mountSubDir/$localIp" | grep -c "_fhem_backup.tar.gz"`
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup backupFiles $backupsCurrent"
echo "Mount wieder unmounten"
umount "$localMountPoint"
FHEM ist auf dem aktuellen Stand von heute ! Ebenfalls das System (wurde rst vor ein paar Tagen neu aufgesetzt).
Wenn ich das Backup manuell startet, kommt folgendes.
pi@raspi:~ $ sudo -u root /opt/fhem/FHEM/backup.sh &
[1] 6363
pi@raspi:~ $ /backup bereits vorhanden
PING 192.168.2.126 (192.168.2.126) 56(84) bytes of data.
64 bytes from 192.168.2.126: icmp_seq=1 ttl=64 time=0.787 ms
--- 192.168.2.126 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.787/0.787/0.787/0.000 ms
192.168.2.126 erreichbar
/Q/backup bereits vorhanden
/Q/backup leer, Mounten starten
mountComplete: //192.168.2.126/Backup /Q/backup cifs username=xxxx,password=xxxx,iocharset=utf8,sec=ntlm 0 0
/etc/fstab: Eintrag bereits vorhanden: //192.168.2.126/Backup /Q/backup cifs username=xxxx,password=xxxxx,iocharset=utf8,sec=ntlm 0 0
Mounts werden aktualisiert
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Mounten hat anscheinend nicht geklappt, skip.
^C
[1]+ Done sudo -u root /opt/fhem/FHEM/backup.sh
Habe dann über die Console versucht folgendes abzusetzen.
perl /opt/fhem/fhem.pl 7072 "setreading FHEM.Backup info backup starting now"
Und im LOG erschien dann das.
2019.09.08 19:08:22 3: Login denied via telnetPort_127.0.0.1_52344
Muss da nochwas in der telnet definition gesetzt werden ? Wenn ja, was?
Die telnet Definition ist die Standart Definition nach einer installation.
In meinem letzten Backup ist die Definition auch gleich, wie jetzt.
Internals:
CONNECTS 6
DEF 7072 global
FD 7
FUUID 5c43026c-f33f-852e-be92-82cff266a5c72359
FVERSION 98_telnet.pm:0.175290/2018-10-14
NAME telnetPort
NR 88
PORT 7072
STATE Initialized
TYPE telnet
READINGS:
2019-09-08 16:37:39 state Initialized
Attributes:
Gruß
Sascha
Du hast scheinbar 2 Probleme:
1. Hört FHEM überhaupt auf telnet?
netstat -ntp | grep 7072
- Ansonsten mal gucken, ob telnet überhaupt offen/definiert ist?
- Alle passenden perl-Libarys installiert 8Wirft FHEM beim Starten Fehlermeldungen?)
2. Hast Du Mount Probleme ... oder Coding-Probleme
mountComplete: //192.168.2.126/Backup /Q/backup cifs username=xxxx,password=xxxx,iocharset=utf8,sec=ntlm 0 0
/etc/fstab: Eintrag bereits vorhanden: //192.168.2.126/Backup /Q/backup cifs username=xxxx,password=xxxxx,iocharset=utf8,sec=ntlm 0 0
Was willst Du mit diesem Kompletten Code??
Hallo Werniemann.
Habe das Script von meintecblog.de damals genommen und mich an die Anleitung gehalten. Dies wurde hier in der Vergangheit ja auch diskutiert.
Wenn ich
netstat -ntp | grep 7072
eingebe, kommt nix, ausser
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Habe in meinem Post ja nochmal das Script mit reingehängt !!
Gruß
Sascha
- Mach die Ausgabe mal aus root
- und in Fhem mal die Ausgabe von (Sofern Du den telnet-Port nicht umbenannt hast)
list telnetPort
Das List vom telnetPort hängt oben in meinem Beitrag zum Schluss dran.
Wenn ich dir Eingabe in der Console mit sudo mache, kommt gar nix.
Gesendet von meinem MI 9 mit Tapatalk
Sorry, Tippfehler:
netstat -lntp | grep 7072
tcp 0 0 0.0.0.0:7072 0.0.0.0:* LISTEN
2774/perl
Gesendet von meinem MI 9 mit Tapatalk
a)
Ich bin etwas auf dem "Holzweg" .. Dein Problem ist eigentlich:
Mounts werden aktualisiert
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Mounten hat anscheinend nicht geklappt, skip.
Da es ein cifs .. hast Du mal probiert manuell zu Mounten? Ich gehe davon aus, das Du die Tools fürs cifs nicht installiert hast ...
b)
Wegen telnet .. mal telnet manuell probiert? Anleitung steht hier irgendwo im Thread ...
Welche Tools für cifs?
Werde mal später testen.
Gesendet von meinem MI 9 mit Tapatalk
Probiere erstmal den Manuelklen Mount. Dann wird dir (hoffentlich) die Fehlermeldung schon etwas sagen
Ich glaube: "cifs-utils"
Hallo Sascha,
hier (https://heinz-otto.blogspot.com/2018/02/windows-server-freigabe-auf-dem.html)findest Du meine Notizen zum Thema cifs.
Ist es eventuell auch ein Problem mit den Versionen? Was hast Du eigentlich geändert?
viele Systeme laufen hartnäckig auf smb1, neuer Linuxe unterstützen aber smb1 nicht mehr per default. Du findest dazu aber einige Infos am Ende meines Artikels. Vielleicht hilft es Dir.
Gruß Otto
Viele Wege führen zum Ziel, gerade in der Linux-Welt. Du kannst es auch mit autofs (https://wiki.debian.org/AutoFs) versuchen (hier im Forum beschrieben (https://forum.fhem.de/index.php/topic,87669.0.html)).
Danke euch.
War ich geändert habe ist, dass ich von jessy auf buster light (ohne Desktop) umgestiegen bin, in ergangen des komplett neu aufsetzen.
Gesendet von meinem MI 9 mit Tapatalk
was für die smb1 Problematik sprechen könnte ...
Du musst also am Besten schauen, dass und wie Du manuell den mount Befehl ausführen kannst. Leichter Test dauert nur minuten :)
Hallo Otto.
Bin noch unterwegs.
Kleiner Tipp wie man manuell mountet?
Gesendet von meinem MI 9 mit Tapatalk
Ja klar, hab ich doch schon geschrieben - steht im Link in #57
Otto: hast Du Deine Antworten im Kopf??
Ich hätte es nicht so schnell gefunden ...
Zitat von: Wernieman am 09 September 2019, 13:00:10
Otto: hast Du Deine Antworten im Kopf??
Ich hätte es nicht so schnell gefunden ...
Naja #57 hab ich ja heute morgen erst geschrieben. Und meinen Blog hab ich ja auch mal selbst geschrieben - da fällt mir (meistens) relativ schnell ein nach was ich suchen muss :)
So. Habe mal gestet, das Backupverzeichniss "/Q/backup" zu mounten.
pi@raspi:~ $ sudo mount /Q/backup
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Habe dann mal von @Otto123 ´s Page folgendes versucht.
sudo mount -t cifs -o username='xxxxxxx',password='xxxxxx',vers=1.0 //192.168.2.126/Backup/FHEM /Q/backup
Angezeigt wurde dann keine Fehlermeldung.
Habe dann mal "df" in der Konsole abgesetzt, und raus kam folgendes.
pi@raspi:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 30400236 5103108 24029756 18% /
devtmpfs 469544 0 469544 0% /dev
tmpfs 474152 0 474152 0% /dev/shm
tmpfs 474152 6332 467820 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 474152 0 474152 0% /sys/fs/cgroup
/dev/mmcblk0p1 258096 40051 218045 16% /boot
tmpfs 94828 0 94828 0% /run/user/1000
//192.168.2.126/Backup/FHEM 1917967448 1626930496 290918168 85% /Q/backup
Die Angabe mit der IP ist mein NAS und "/Q/backup" ist das Verzeichniss auf dem pi, wo das Backup angelegt werden soll, was ja auch schon vorhanden ist.
Habe dann von Otto´s Page auch noch mal das
"cat /proc/filesystems" in der konsole abgesetzt und raus kam:
pi@raspi:~ $ sudo cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev ramfs
nodev bdev
nodev proc
nodev cpuset
nodev cgroup
nodev cgroup2
nodev tmpfs
nodev devtmpfs
nodev configfs
nodev debugfs
nodev tracefs
nodev sockfs
nodev pipefs
nodev rpc_pipefs
nodev devpts
ext3
ext2
ext4
vfat
msdos
nodev nfs
nodev nfs4
nodev autofs
f2fs
nodev mqueue
nodev cifs
nodev smb3
Hilft das jemanden weiter ?
gruß und Danke
Sascha
Probiere mal bitte, ob es auch mit "vers=2.0" funktioniert ...
So in etwa ?
pi@raspi:~ $ sudo mount -t cifs -o username='xx',password='xx',vers=2.0 //192.168.2.126/Backup/FHEM /Q/backup
pi@raspi:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 30400236 5103164 24029700 18% /
devtmpfs 469544 0 469544 0% /dev
tmpfs 474152 0 474152 0% /dev/shm
tmpfs 474152 6332 467820 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 474152 0 474152 0% /sys/fs/cgroup
/dev/mmcblk0p1 258096 40051 218045 16% /boot
tmpfs 94828 0 94828 0% /run/user/1000
//192.168.2.126/Backup/FHEM 1917967448 1627049280 290918168 85% /Q/backup
ja .. aber vorher bitte entmounten ...
habe ich vorher gemacht.
In dem Script werden ja per telnet die Readings in FHEM gestzt.
Hier nochmal das List vom telnet.
Es wird dann der Zugriff verweigert, steht so im LOG
Internals:
CONNECTS 11
DEF 7072 global
FD 7
FUUID 5c43026c-f33f-852e-be92-82cff266a5c72359
FVERSION 98_telnet.pm:0.175290/2018-10-14
NAME telnetPort
NR 88
PORT 7072
STATE Initialized
TYPE telnet
READINGS:
2019-09-08 16:37:39 state Initialized
Attributes:
room 99_System
Zitatpi@raspi:~ $ sudo mount /Q/backup
mount error(22): Invalid argument
Das kann doch eigentlich nur bedeuten, das etwas in der fstab falsch ist?
Manuell mounten geht ja :)
Zur Sicherheit könntest Du mal folgendes machen und die Ausgabe posten
cat /etc/fstab
ls -lha /etc/fstab
pi@raspi:~ $ cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=fd6b9861-01 /boot vfat defaults 0 2
PARTUUID=fd6b9861-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
//192.168.2.126/Backup /Q/backup cifs username=xxx,password=xxx,iocharset=utf8,sec=ntlm 0 0
pi@raspi:~ $ ls -lha /etc/fstab
-rw-r--r-- 1 root root 415 Sep 9 18:19 /etc/fstab
ich denke er hat mit dem Parameter sec=ntlm Probleme, ich meine sowas schon gelesen zu haben.
Wenn Du den mal weglässt?
/192.168.2.126/Backup /Q/backup cifs username=xxx,password=xxx,iocharset=utf8 0 0
Mit der Option users bräuchte man auch kein sudo :)
So. Mal eben ein Rückmeldung.
Habe das ins Script eingefügt, von Otto.
do
mountComplete="//$mountIp/$mountDir $localMountPoint cifs username=$mountUser,password=$mountPass,iocharset=utf8 0 0"
echo "mountComplete: $mountComplete"
Habe dann das Backup manuell ausgelöst.
Und siehe, da. Es funktioniert. Die ganzen Backup Dateien, die während den Testläufen sich angehäuft haben, wurden dann in einem Rutsch auf das NAS geschoben.
TOP. Danke an Euch !!!!
Habe jetzt noch ein anderes Problem.
Der Zugriff über TelnetPort 7072 funktioniert nicht. Durch das Script werden im Dummy die Readings gesetzt. Sollte so sein....... Klappt aber nicht
Das das evtl. OT ist, einen neuen Thread aufmachen ??
Gruß und Danke
Sascha
Hallo Sascha,
mach mal list telnetPort
Gruß Otto
Steht oben in #70
Gesendet von meinem MI 9 mit Tapatalk
Du kommst mit einer nicht privaten Class C IP Adresse?
Du kommst aus einem anderen IP Segment?
Du hast ein allowed definiert?
Probier mal auf dem gleichen Rechner wie FHEM läuft so was im Terminal:
perl /opt/fhem/fhem.pl 7072 "list global"
Oder in der FHEM Komamndozeile, allerdings landet die Ausgabe im Logfile
"perl /opt/fhem/fhem.pl 7072 "list global""
alternativ mit "Bordmitteln":
echo "list" | nc localhost 7072
Egal welcher der 3 Methoden ich nehme, es kommt folgendes raus.
LOG aus fhem
2019.09.11 21:13:59 1: Connection refused from 127.0.0.1:56068
Use of uninitialized value in numeric gt (>) at /opt/fhem/fhem.pl line 526.
2019.09.11 21:13:29 1: Connection refused from 127.0.0.1:56034
2019.09.11 21:13:04 1: Connection refused from 127.0.0.1:56022
2019.09.11 21:12:54 1: Connection refused from 127.0.0.1:56010
konsole
pi@raspi:~ $ perl /opt/fhem/fhem.pl 7072 "list global"
Use of uninitialized value in numeric gt (>) at /opt/fhem/fhem.pl line 526.
Alle Meldungen finde ich atypisch :(
Mir fehlt hier jetzt eine weiter Idee zu Suche.
Alternative Idee: Lad meinen FHEM HHTP Client (https://heinz-otto.blogspot.com/2019/02/fhem-http-client.html) herunter.
Geht sehr leicht so mit den Anführungszeichen in der FHEM Komamndozeile, da stimmt dann der Ort und die Rechte!
"wget -qO fhemcl.sh https://raw.githubusercontent.com/heinz-otto/fhemcl/master/fhemcl.sh"
probiere im Terminal
bash /opt/fhem/fhemcl.sh 8083 "list global"
Und wenn das funktioniert: stelle dein Script entsprechend um :)
was soll denn als ausgabe im terminal kommen ????
passiert nix
Gruß
Sascha
na die Antwort von list global
So als ob Du es in der FHEM Kommandozeile eingibst :[
was passiert bei ping localhost im Terminal?
kommt aber nix
pi@raspi:~ $ bash /opt/fhem/fhemcl.sh 8083 "list global"
pi@raspi:~ $ bash /opt/fhem/fhemcl.sh 8083 "list global"
pi@raspi:~ $ ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.215 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.158 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.220 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.213 ms
64 bytes from localhost (::1): icmp_seq=5 ttl=64 time=0.223 ms
64 bytes from localhost (::1): icmp_seq=6 ttl=64 time=0.171 ms
64 bytes from localhost (::1): icmp_seq=7 ttl=64 time=0.225 ms
Ich hab das gleiche Backup laufen.
Kann dir morgen meine telnet und Backup config posten.
Gesendet von meinem S60 mit Tapatalk
danke.
muss irgendwie bei allowdfrom oder so noch was eingetragen werden.
Es geht hier nur um das lokale heimnetzwerk.
Dein FHEMWEB läuft nicht auf Port 8083?
Du verwendest HTTPS?
Du hast allowed eingerichtet für WEB?
Es läuft eine Firewall?
Es läuft ein Proxy?
was gibt dir das zurück?
curl -s -D - "http://localhost:8083/fhem?XHR=1"
Oder in FHEM
list TYPE=allowed
Zitat von: Otto123 am 11 September 2019, 22:04:14
Dein FHEMWEB läuft nicht auf Port 8083?
Du verwendest HTTPS?
Du hast allowed eingerichtet für WEB?
Es läuft eine Firewall?
Es läuft ein Proxy?
was gibt dir das zurück?
curl -s -D - "http://localhost:8083/fhem?XHR=1"
pi@raspi:~ $ curl -s -D - "http://localhost:8083/fhem?XHR=1"
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="FHEM: login required"
Content-Length: 0
Port 8083 ist erreichbar.
Firewall auf Pi? Nein.
HTTPS ? Nein
Internals:
FUUID 5c43026d-f33f-852e-1196-351a4c59f38ba880
FVERSION 96_allowed.pm:0.200690/2019-08-27
NAME allowed_WEB
NR 91
STATE validFor:WEB,mqtt,telnetPort
TYPE allowed
validFor WEB,mqtt,telnetPort
READINGS:
2019-09-11 22:11:04 state validFor:WEB,mqtt,telnetPort
Attributes:
basicAuth xxxx
globalpassword xxxx
password xxx
room 99_System
validFor WEB,mqtt,telnetPort[code]
WWW-Authenticate: Basic realm="FHEM: login required"
Danke das wir drüber gesprochen haben :'(
wenn Du noch willst: ruf einfach bash /opt/fhem/fhemcl.sh auf. Das steht wie Du es mit Login verwenden kannst.
Oder Du musst dein Login beim Telnet im Script angeben.
Werde die Anmeldung mal raus nehmen
Gesendet von meinem MI 9 mit Tapatalk
Oder mal probieren:
echo -en "<password>\nlist" | nc localhost 7072Bitte <passwort> anpassen ...
Telnet:
defmod telnetPort telnet 7072 global
allowed Telnet:
defmod allowed_telnetPort allowed
attr allowed_telnetPort password 12345678!
attr allowed_telnetPort validFor telnetPort
Backup Config:
#!/bin/bash
mountIp="192.168.xxx.yyy"
....
localMountPoint="/Q/backup"
#optional
mytelnetPW="12345678!"
...
läuft so wunderbar. PW ist natürlich geändert. ;)
ZitatIch habe mein System komplett neu aufgesetzt. Habe entsprechend ein Update von Raspbian auf Buster am laufen.
Vorher hat das Backup, eingerichtet nach meintechblog, ohne Probleme funktioniert.
Habe nachdem aufsetzen des Systems dann FHEM aus dem letzten Backup zurück kopiert, rechte vergben, etc. FHEM läuft soweit.
Habe jetzt aber festgestellt, dass das Backup nicht läuft.
Hat sich bei Buster etwas geändert ?
Moin,
um die ursprüngliche Frage zu beantworten. In Buster ist die Verwendung von cifs offenbar leicht angepasst, so dass ein wie alt auch immer Syntax nicht mehr funktioniert. Eventuell wurden im Syntax einfach alte Zöpfe abgeschnitten, dass passiert bei Entwicklungen immer wieder.
Aber! Du hast entweder entgegen Deiner Aussagen den Zugang zu deinem FHEM verändert und Dein Backupscript nicht angepasst oder das Backup Script ist bezüglich telnet Zugang so noch nie gelaufen!
Zitat von: sash.sc am 11 September 2019, 22:22:02
Werde die Anmeldung mal raus nehmen
Das macht auch keinen Sinn. Du musst vielmehr immer im Hinterkopf haben:
- dass Du eine Anmeldung hast,
- diese nicht verschweigen und für Dich selbst ignorieren und
- Nachfragen von Anderen nach der Anmeldung nicht einfach mehrfach ignorieren.
Und jetzt die Anmeldung einfach in Dein Script einbauen. ;D
Gruß Otto
Asche auf mein Haupt.
Ich bin geläutert. [emoji6]
Das Backup lief immer. Es wurde fleißig auf dem NAS gesichert. Es wurden nur nie die Readings geschrieben.
Das war mir wohl aufgefallen.
Habe dann nur ein at gesetzt, welches den Dummy immer wieder zurück gesetzt hat. Dies sollte ja auch von dem script gemacht werden.
Werden dann die Anmeldung wieder einbauen und die hier von euch gelieferten Infos mit berücksichtigen.
Ein dickes Lob für eure Unterstützung!
Danke.
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Hallo Sascha,
tust Du mir noch einen Gefallen?
Probierst Du mal noch meinen HTTP Client bei Dir? Also einfach mal:
bash /opt/fhem/fhemcl.sh
Sagen ob Du verstehst was da steht und dann mit deinem Login probieren
bash /opt/fhem/fhemcl.sh <url mit Login zu Deinem FHEM> "list global"
Und sagen ob das klappt.
Wäre schön wenn es mal jemand testet :)
Gruß Otto
Werde ich testen..
Werde aber wohl erst am WE dazu kommen.
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
gar keine Eile :)
Hat mir jetzt keine Ruhe gelassen.
Habe Passwörter/Login mal zum testen entfernt.
Habe das nochmal ausprobiert.
pi@raspi:~ $ curl -s -D - "http://localhost:8083/fhem?XHR=1"
HTTP/1.1 200 OK
Content-Length: 0
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: text/plain; charset=UTF-8
Habe dann dein HTTP Client von dir installiert. wie in #79.
Das war die Antwort
pi@raspi:~ $ bash /opt/fhem/fhemcl.sh 8083 "list global"
Unknown command no, try help.
Unknown command fhemcl.sh, try help.
Unknown command fhemcl.sh, try help.
Unknown command lines, try help.
Unknown command <hosturl>, try help.
Unknown command <hosturl>, try help.
Unknown command except, try help.
Gruß
sascha
Du hast den csrf Token ausgeschaltet.
Die anderen Meldungen versteh ich nicht :(
Sieht aus als ist die Datei kaputt ...
Kannst Du dies testen?
bash /opt/fhem/fhemcl.sh
pi@raspi:~ $ bash /opt/fhem/fhemcl.sh
no command given, hosturl was http://localhost:8083
fhemcl.sh <hosturl> "FHEM command1" "FHEM command2"
fhemcl.sh <hosturl> filename
lines from pipe like echo -e "set Aktor01 toggle" | fhemcl.sh [<hosturl>]
<hosturl> default is $prot://$host:$port
<hosturl> Argument could be any part of http://user:password@hostName:portNumber
except user:password@ any missing part is added from default
Das sieht nicht aus wie kaputt.
Was nutzt Du für ein Terminal?
Die Ausgabe oben sieht aus wie der Hilfetext als Befehle interpretiert - sehr eigenartig :(
putty
Funktioniert bei mir auch in putty
Welche Version hast Du?
lsb_release -a
pi@raspi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
ist die light version
Guten Morgen,
ich bin etwas ratlos. Aber ich will Dich damit auch nicht ewig behelligen. Ich habe das unter allen raspbian Versionen ab wheezy getestet und auch vorhin nochmal unter genau Deiner Version. Es gibt bei mir keine Auffälligkeit.
Bei Dir gibt er, wenn Du den list Befehl übergibst, ja offenbar meinen "Hilfetext" direkt in die Kommandozeile anstatt den Befehl an FHEM zu schicken. Da habe ich keine Ahnung wie das passieren kann.
Da hab ich wohl irgendeine Unzulänglichkeit eingebaut die ich nicht überblicke.
Gruß Otto
Ist zwar keine direkte Antwort, bezieht sich aber aufs Thema. Bei mir (fhem auf RPI3 mit buster) hat folgendes funktioniert.
Eintrag in fstab:
<Pfad Netzwerk-Ordner> <lokaler Pfad> cifs credentials=/home/pi/.credentials,uid=fhem 0 0
Damit wird der User "fhem" bei den eingebundenen Dateien als Besitzer gesetzt. Dann funktioniert auch die eingebaute Backup-Funktion von FHEM, wenn man zusätzlich in der FHEM-Config noch setzt:
attr global backupdir <lokaler Pfad>
Es empfiehlt sich die Login-Daten für den smb-share nicht direkt in die fstab zu schreiben, sondern in eine separate Datei (z.B. /home/pi/.credentials) auszulagern. Diese hat den Inhalt:
username=<smb-username>
password=<smb-pasword>
Für diese Datei sollten dann restriktive Berechtigungen gesetzt werden; z.B:
sudo chmod 0600 /home/pi/.credentials
Hallo zusammen.
habe da ein problem mit der Backup routine. Bin mit Fhem auf nen neuen RPI gewechselt (4b).
Habe den user und password auch neu gesetzt in der backup.sh
es scheint aber ein problem mit dem mounten zu geben.
Hier der auszug aus dem log von fhem.
Mounten hat anscheinend nicht geklappt, skip.
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
mount error(13): Permission denied
Mounts werden aktualisiert
/etc/fstab: Eintrag bereits vorhanden: //192.168.2.126/zuhause/backup /Q/backup cifs username=xx,password=xxx,iocharset=utf8 0 0
mountComplete: //192.168.2.126/zuhause/backup /Q/backup cifs username=xx,password=xx,iocharset=utf8 0 0
/Q/backup leer, Mounten starten
/Q/backup bereits vorhanden
192.168.2.126 erreichbar
rtt min/avg/max/mdev = 1.051/1.051/1.051/0.000 ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms
--- 192.168.2.126 ping statistics ---
64 bytes from 192.168.2.126: icmp_seq=1 ttl=64 time=1.05 ms
PING 192.168.2.126 (192.168.2.126) 56(84) bytes of data.
/backup bereits vorhanden
Anstatt Buster habe ich jetzt Bullseye als Systemversion
Den Benutzer fhem habe ich extra auf dem nas angelegt und auch die rechte für das zielverzeichnis gesetzt (Vollzugriff).
Bin mit meinem latein am ende !
Jemand eine Idee.
gruß und danke
Sascha
P.S.:
habe noch aus dmesg folgendes heraus geholt
[ 624.245759] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[ 624.245775] CIFS: Attempting to mount \\192.168.2.126\zuhause
[ 624.611682] CIFS: VFS: cifs_mount failed w/return code = -2
[ 1353.288303] CIFS: Attempting to mount \\192.168.2.126\zuhause
[ 1353.650475] CIFS: VFS: cifs_mount failed w/return code = -13
So, ahbe die vorherigen posts nochmal durchgeschaut.
Habe dann mal manuell gemountet.
sudo mount -t cifs -o username='xxx',password='xxx',vers=3.0 //192.168.2.126/Backup/FHEM /Q/backup
Mit dem neu angelegten User "FHEM". Der Unetrschied war wohl das vers=3.0.
Auf neueren Systemen wird SMB (Samba) v1 nicht mehr unterstützt. Daher musste die Angabe größer Version 2.1 sein (nach den Logauszügen).
Also 1x manuell gemountet, das Script dann manuell gestartet und abgewartet.
Dann wurden alle Backups rübergeschoben auf das NAS.
Habe das Backup Script noch angepasst.
do
mountComplete="//$mountIp/$mountDir $localMountPoint cifs vers=3.0,username=$mountUser,password=$mountPass 0 0"
echo "mountComplete: $mountComplete"
Gruß
Sascha
Normalerweise ist die Angabe einer Version nicht nötig. Nur wenn man "veraltete" benötigt.
genaugenommen ist die Angabe vers=3.0 kontraproduktiv, da dadurch ev. eine alte Version genommen wird. siehe https://wiki.ubuntuusers.de/mount.cifs/#SMB-Protokoll-Versionen
Also weglassen und diese Option nur verwenden wenn man wirklich eine alte Version nehmen muss.
Hallo,
ich habe da mal eine Frage .
Habe mir jetzt ein FHEM auf einem NUC mit Ubundu installiert.
Habe mich auch stikt an die Anweisungen für das Backup gehalten.
Aber leider wird mein NAS nicht gemountet.
Bei dem noch laufenden FHEM auf einem Raspi funktioniert es problemlos.
Was muss ich evtl. bei Ubundu anders machen ?
Damit soll gemountet werden
sudo mount -t nfs -o soft 192.168.113.192:/mnt/HD/HD_a2/fhembackup /Q/backup
gibt es eine Fehlermeldung?
Möglichkeiten:
sudo geht nicht?
NFS export auf der NAS ist nicht für diese IP gemacht?
Zum nachlesen https://wiki.ubuntuusers.de/NFS/
Hallo Otto,
vielen Dank für Deine Antwort.
Ich bekomme nur bei SQl diese Meldung :
Can't open file '/Q/backup/rpi/fhem/192.168.112.103/fhem_2024_03_26_04_00.sql' for write access
Bezüglich NFS , wie ich schon geschrieben habe, läuft das auf einem Raspi problemlos schon Zwei Jahre .
Also muss es doch so funktionieren.
Ich denke ich bekomm einfach keinen Mount hin , oder ?
Gruß
Wendelin
was bekommst Du in der FHEM Kommandozeile damit zurück?
{qx(ls -lha /Q/backup/)}{qx(ls -lha /Q/backup/rpi/fhem/192.168.112.103/)}
Hallo Otto,
Beim ersten befehl
insgesamt 8,0K
drwxr-xr-x 2 root root 4,0K Mär 14 21:54 .
drwxr-xr-x 3 root root 4,0K Mär 14 21:54 ..
Beim zweiten , keine Meldung
Gruß
Wendelin
Guten Abend,
naja das ist nur der Mountpoint, da ist nicht gemounted. Insofern ist dein "SQL Zugriff" sinnlos bzw. läuft ins leere.
Was liefert Dir:
{qx(showmount -e 192.168.113.192)}
Gruß Otto
Guten Abend Otto,
Die Eingabe liefert keine Ausgabe und keinen Fehler
Gruß
Wendelin
dann gibt es mMn unter dieser IP keine NFS Freigabe die Du mounten könntest.
Ist die IP richtig und vom FHEM erreichbar?
Kannst Du dich auf diese IP per Terminal verbinden und dort ein cat /etc/exporteingeben?
Hallo Otto,
vielen Dank bis hierher.
Aktuell bin ich im Ausland und habe erst am Freitag wieder vorort zugriff auf das System. Mit Fhem kann ich mich zwar über den Port 8083 verbinden , aber leider nicht mit dem System selbst, dafür muss ich noch den ssh server einrichten.
Würde aber sehr gern hier am Freitag weitermachen. Bis dahin
VG
Wendelin