FHEM auf Raspi nicht mehr erreichbar

[Conti]

Hallo allerseits

nachdem ich mich durch die Themen 'FHEM nicht mehr erreichbar' hier im Forum durchgelesen habe, versuche ich es mit einer Frage.

FHEM lief bisher einwandfrei.
Als ich über die Kommandozeile in FHEM ein define absetzen wollte, fiel mir auf das die cfg nicht mehr gespeichert werden konnte.
Bei einem Blick in das Log sah ich die Meldung

Code Auswählen Erweitern

WriteStatefile: Cannot open ./log/fhem.save: Permission denied und

Code Auswählen Erweitern

Can't open ./log/fhem-2017-09.log: Permission denied at fhem.pl line 2571.

Daraufhin habe ich als erste Massnahme den FHEM Status abgefragt und es lief.
Dann FHEM gestoppt mit der Hoffnung nach einem FHEM start wieder alles am laufen zu haben.

Leider lässt sich FHEM nicht mehr starten.
Ein

Code Auswählen Erweitern

sudo /etc/init.d/fhem start gibt mir immer die Meldung

Code Auswählen Erweitern

Can't open ./log/fhem-2017-09.log: Permission denied at fhem.pl line 2571.

Interessanterweise kann ich von meinem MAC aus über AFP auch nicht mehr auf das Dateisystem.
Der Raspi läuft aber Problemlos und SSH funktioniert.

Kann mir jemand weiterhelfen?

Besten Dank im Voraus
Conti

[CoolTux]

linux Permission denied bei google eingeben. Dann findest Du einige Treffer bezüglich Rechte von Dateien und Verzeichnissen. Da kannst Du ansetzen.

[gloob]

Ich würde eher prüfen, warum die Rechte auf einmal anders sind. Hast du was am Raspbian geändert?
Möglicherweise hat die SD Karte auch einen Defekt. Dann lohnt sich ein Reparieren der Rechte nicht und ich würde die Karte ersetzen.

[Wernieman]

Um dieses zu prüfen:
Auf dem RasPi einloggen (ssh)
- Rechte prüfen (ls -lha /opf/fhem)
- Einfach mal eine Datei anlegen (touch /opf/fhem/testdatei)
- das kern-log prüfen a) (tail -n50 /var/log/kern.log) b) "grep -i i/o /var/log/kern.log"

[Conti]

Vielen Dank für die tipps!

Am Raspi habe ich nichts geändert.
Darum habe ich mich auch gewundert wieso plötzlich Probleme mit den Rechten auftauchen.
Ev. gehts es eher in die Richtung die gloob anspricht.
Ich habe aus Platzgründen das ganze Verzeichnis /opt auf einen usb stick ausgelagert.
Ist allerdings nicht der neueste. Würde mich nicht wundern wenn dieser ein Schuss hätte.
Werde mal mit den tipps von Wernieman genauer reinschauen und die Erkenntnisse wieder posten.

Vielen Dank.
Conti

[Wernieman]

/opt auf einen usb stick ausgelagert.

Oder Du hast einen USB-Wackler und das Dateisystem ist "read onyl"

Code Auswählen Erweitern

mount | grep opt

[Conti]

So der usb stick ist beschreibbar. Datei in /opt/fhem angelegt und wieder gelöscht.

Zum versuch habe ich bei den Dateien im /opt/fhem/log fhem.save und fhem.cfg ein chmod 777 angewandt.
Danach lässt sich fhem wieder starten und es läuft wie erwartet.

Wieso können Rechte plötzlich überschrieben werden?
Ich gehe davon aus dass 777 nicht unbedingt gut ist. Im moment ist fhem nicht von aussen erreichbar darum ist das Risiko wohl nicht gross.
Wie müsste es korrekt sein?

Viele Grüsse
Conti

[CoolTux]

Dateien 644 und Verzeichnisse 755
Du kannst ein chmod -R 755 /opt/fhem/
machen

[Wernieman]

Und vorher nachsehenh, WEM die Dateien gehören:

Code Auswählen Erweitern

ls -lha /opf/fhem

Grundsätzlich:
Gewöhne Dir an zuerst zu gucken und dann "irgendwass zu machen". Wenn 777 läuft, es aber vorher nicht, gehörten die Dateien warscheinlich einem falschen User. Hast Du Dich eventuell als "Pi" eingeloggt (ssh) und etwas gemacht?

[Conti]

Hallo Wernieman

besten Dank für Deine Hilfe und die nützlichen Tips.
Ja, ich logge mich nur mit dem user PI ein und ich gebe Dir recht. Bevor ich die Rechte aufmache hätte ich schauen sollen wer sie überhaupt hat.
Ich meine es war root. Aber eben...

Habe jetzt die Hammermethode gewählt und alles Platt gemacht weil ich anders vorgehen möchte.
Trotzdem viel gelernt. Danke.

Conti