NEWS
[Gelöst]zigbee funktioniert nicht mehr nach upd auf bullseye
-
Jetzt war ich gerade mit allem fertig da ist plötzlich im Zigbee Adapter alles leer gewesen. Hab den Com Port wieder eingestellt und die Gerät sind aufgetaucht, aber PAN ID, erweiterete PAN ID und Transportschlüssel sind leer... Jetzt muss ich wieder von vorne anfangen. Backup zurückspielen von influxdb und zigbee geht auch nicht. Da ist doch echt der Wurm drin.
/€ zigbee backup musste ich erst lokal rüberkopieren, dann durfte ich es installieren. Per cifs war immer root/root eingetragen. Bis auf einen Sensor hab ich jetzt alles wieder drin, der eine will leider nicht. Influxdb geht auch wieder. Ich fass jetzt nix mehr an und will die nächsten Wochen nix mehr damit zu tun haben :)
Die Lösung war also vermutlich ein falsches Setting im Conbee II was ich erst im Debug Log vom deconz-gui über Windows gesehen haben...
@skinni sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
zigbee backup musste ich erst lokal rüberkopieren, dann durfte ich es installieren. Per cifs war immer root/root eingetragen.
Dann ist dein Backitup-Adapter nicht richtig eingestellt. Oder die Freigaben. Üblicherweise geht das natürlich auch über ein gemountetes Dateisystem.
-
@skinni sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
zigbee backup musste ich erst lokal rüberkopieren, dann durfte ich es installieren. Per cifs war immer root/root eingetragen.
Dann ist dein Backitup-Adapter nicht richtig eingestellt. Oder die Freigaben. Üblicherweise geht das natürlich auch über ein gemountetes Dateisystem.
@thomas-braun , genauso ist es.
@skinni , man muss natürlich nach einer neu Installation zuerst das NAS einrichten und die Pfadangabe machen. Ich nutze NFS. Woher soll das Backitup nach dem ersten Start wissen?
Vor der IOB Installation hänge ich mein NAS via autofs ein.
-
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker, das gab dann Zugriffsverletzungen beim Zurückspielen. Hab auch etliche Threads dazu gefunden, aber nie ne Lösung.
Da ich auf dem gemounteten Verzeichnis die Berechtigungen nicht ändern konnte hab ichs halt rüberkopiert und dann angepasst
-
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker, das gab dann Zugriffsverletzungen beim Zurückspielen. Hab auch etliche Threads dazu gefunden, aber nie ne Lösung.
Da ich auf dem gemounteten Verzeichnis die Berechtigungen nicht ändern konnte hab ichs halt rüberkopiert und dann angepasst
-
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker, das gab dann Zugriffsverletzungen beim Zurückspielen. Hab auch etliche Threads dazu gefunden, aber nie ne Lösung.
Da ich auf dem gemounteten Verzeichnis die Berechtigungen nicht ändern konnte hab ichs halt rüberkopiert und dann angepasst
@skinni sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker
Das erkläre mal genauer!
Für mich ist logisch das im Backup auf dem Nas nicht IOB ist.
Aber IOB greift aufs NAS zu....auf die Backupfiles -
Wenn ich das richtig verstanden habe, werden die files vom backitup Adapter nach /opt/iobroker/backups gemounted, allerdings ist dann root der Eigentümer und es gibt beim Zurücksichern eine Fehlermeldung.
Mit sudo chown iobroker:iobroker /opt/iobroker/backups/* konnte ich die Berechtigungen so setzen, dass ich zurücksichern darf. Allerdings nur, wenn ich das Verzeichnis vorher nicht gemountet habe sondern die Dateien tatsächlich dorthin kopiert habe.
Hoffe das war verständlich.
Im Adapter selbst kann man dahingehend ja nicht viel einstellen, noserverino oder nicht macht auch keinen Unterschied.
/€ hier war das gleiche Problem: https://213.136.68.177/topic/42424/wie-gelöschten-zigbee-adapter-wieder-herstellen/45
-
Wenn ich das richtig verstanden habe, werden die files vom backitup Adapter nach /opt/iobroker/backups gemounted, allerdings ist dann root der Eigentümer und es gibt beim Zurücksichern eine Fehlermeldung.
Mit sudo chown iobroker:iobroker /opt/iobroker/backups/* konnte ich die Berechtigungen so setzen, dass ich zurücksichern darf. Allerdings nur, wenn ich das Verzeichnis vorher nicht gemountet habe sondern die Dateien tatsächlich dorthin kopiert habe.
Hoffe das war verständlich.
Im Adapter selbst kann man dahingehend ja nicht viel einstellen, noserverino oder nicht macht auch keinen Unterschied.
/€ hier war das gleiche Problem: https://213.136.68.177/topic/42424/wie-gelöschten-zigbee-adapter-wieder-herstellen/45
@skinni sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
allerdings ist dann root der Eigentümer und es gibt beim Zurücksichern eine Fehlermeldung.
Durch die mount-Optionen
file_mode=0777,dir_mode=0777darf das keine Rolle spielen. Da darf dann Hinz und Kunz alles, egal welchem user oder group die Datei gehört.
-
@skinni sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
allerdings ist dann root der Eigentümer und es gibt beim Zurücksichern eine Fehlermeldung.
Durch die mount-Optionen
file_mode=0777,dir_mode=0777darf das keine Rolle spielen. Da darf dann Hinz und Kunz alles, egal welchem user oder group die Datei gehört.
@thomas-braun Wie gesagt, ich hab nicht so viel Ahnung davon, ich kann nur sagen wie es sich verhält, nicht wieso. Gemountet gings nicht, ich hab die Datei rüberkopiert und es ging nicht, nach chown gings.
/€ das war übrigens auch meine Lösung bei der influx db
-
@thomas-braun Wie gesagt, ich hab nicht so viel Ahnung davon, ich kann nur sagen wie es sich verhält, nicht wieso. Gemountet gings nicht, ich hab die Datei rüberkopiert und es ging nicht, nach chown gings.
/€ das war übrigens auch meine Lösung bei der influx db
Ich würde behaupten, dein System ist schräg.
-
Ich würde behaupten, dein System ist schräg.
@thomas-braun Nagelneu, ich hab nix zusätzlich außer iobroker und mit backitup wiederhergestellt
2022-12-16 22:16:23.662 - info: host.iobroker stopInstance system.adapter.zigbee.0 send kill signal 2022-12-16 22:16:23.673 - info: zigbee.0 (23216) terminating 2022-12-16 22:16:23.676 - info: zigbee.0 (23216) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2022-12-16 22:16:24.344 - info: host.iobroker instance system.adapter.zigbee.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2022-12-16 22:16:24.344 - info: host.iobroker instance system.adapter.zigbee.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2022-12-16 22:16:26.341 - error: backitup.0 (10345) [zigbee] Zigbee Restore not completed 2022-12-16 22:16:26.342 - error: backitup.0 (10345) [zigbee] Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/zigbee_0/' 2022-12-16 22:16:26.341 - error: backitup.0 (10345) [zigbee] Zigbee Restore not completed 2022-12-16 22:16:26.342 - error: backitup.0 (10345) [zigbee] Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/zigbee_0/'
pi@iobroker:/opt/iobroker/backups $ ls -la total 6518940 drwxrwxrwx 2 root root 0 Dec 16 22:11 . drwxrwxr-x+ 6 iobroker iobroker 4096 Dec 16 13:55 .. -rwxrwxrwx 1 root root 4796172 Mar 1 2022 2022_03_01-20_18_16_backupiobroker.tar.gz -rwxrwxrwx 1 root root 4751506 Mar 6 2022 2022_03_06-10_26_28_backupiobroker.tar.gz -rwxrwxrwx 1 root root 5725041 Dec 15 18:13 2022_12_15-18_13_22_backupiobroker.tar.gz -rwxrwxrwx 1 root root 2172 Jun 15 2021 grafana_2021_06_15-23_51_51_backupiobroker.tar.gz -rwxrwxrwx 1 root root 2169 Jun 16 2021 grafana_2021_06_16-02_40_31_backupiobroker.tar.gz usw... -
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker, das gab dann Zugriffsverletzungen beim Zurückspielen. Hab auch etliche Threads dazu gefunden, aber nie ne Lösung.
Da ich auf dem gemounteten Verzeichnis die Berechtigungen nicht ändern konnte hab ichs halt rüberkopiert und dann angepasst
Die gemounteten Dateien sehen im Moment des Backup natürlich so aus:
echad@chet:~ $ ls -la /opt/iobroker/backups/ total 102100 drwxrwxrwx 2 root root 0 Dec 16 22:01 . drwxrwxr-x+ 6 iobroker iobroker 4096 Dec 16 19:47 .. -rwxrwxrwx 1 root root 3377 Dec 10 03:42 historyDB_2022_12_10-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 16:34 historyDB_2022_12_10-16_34_09_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 16:37 historyDB_2022_12_10-16_37_41_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 17:09 historyDB_2022_12_10-17_09_53_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3104 Dec 11 03:42 historyDB_2022_12_11-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3067 Dec 12 03:42 historyDB_2022_12_12-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3531 Dec 13 03:42 historyDB_2022_12_13-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3118 Dec 14 03:42 historyDB_2022_12_14-03_42_32_chet_backupiobroker.tar.gzWenn das Backup durch ist und das Dateisystem wieder ausgehängt ist dann natürlich wieder leer:
echad@chet:~ $ ls -lA /opt/iobroker/backups/ total 0 -
Die gemounteten Dateien sehen im Moment des Backup natürlich so aus:
echad@chet:~ $ ls -la /opt/iobroker/backups/ total 102100 drwxrwxrwx 2 root root 0 Dec 16 22:01 . drwxrwxr-x+ 6 iobroker iobroker 4096 Dec 16 19:47 .. -rwxrwxrwx 1 root root 3377 Dec 10 03:42 historyDB_2022_12_10-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 16:34 historyDB_2022_12_10-16_34_09_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 16:37 historyDB_2022_12_10-16_37_41_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3275 Dec 10 17:09 historyDB_2022_12_10-17_09_53_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3104 Dec 11 03:42 historyDB_2022_12_11-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3067 Dec 12 03:42 historyDB_2022_12_12-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3531 Dec 13 03:42 historyDB_2022_12_13-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 root root 3118 Dec 14 03:42 historyDB_2022_12_14-03_42_32_chet_backupiobroker.tar.gzWenn das Backup durch ist und das Dateisystem wieder ausgehängt ist dann natürlich wieder leer:
echad@chet:~ $ ls -lA /opt/iobroker/backups/ total 0@thomas-braun Ja aber so bekomm ich halt den Fehler. Kopiere ich die "von Hand" in das Verzeichnis und ändere den Besitzer, nur dann darf ich zurücksichern.
-
NAS war natürlich verbunden, aber die files lagen da mit root Berechtigungen und nicht iobroker, das gab dann Zugriffsverletzungen beim Zurückspielen. Hab auch etliche Threads dazu gefunden, aber nie ne Lösung.
Da ich auf dem gemounteten Verzeichnis die Berechtigungen nicht ändern konnte hab ichs halt rüberkopiert und dann angepasst
Das mit der utime hatten wir die Tage schon mal. Ich weiß aber nicht ob oder wie das gelöst wurde.
Das hat aber nicht mit den Rechten an der Datei zu tun, die passen schon. Es kann lediglich das Attibut nicht gesetzt werden.Vielleicht weiß @simatec wo da der Hase im Pfeffer liegt.
-
Wenn da mal nicht mit sudo zuviel gehandhabt wurde. Ich habe auch schon einige Installationen hinter mir, aber irgendwelche Probleme mit Berechtigungen hatte ich so nie. Wenn es mal ein Problem gab, habe ich den Fixer drüber laufen lassen und gut war. Sudo nutzt man nur ausserhalb von IOB und in gar kein Fall volles Root-Recht.
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
Wenn da mal nicht mit sudo zuviel gehandhabt wurde. Ich habe auch schon einige Installationen hinter mir, aber irgendwelche Probleme mit Berechtigungen hatte ich so nie. Wenn es mal ein Problem gab, habe ich den Fixer drüber laufen lassen und gut war. Sudo nutzt man nur ausserhalb von IOB und in gar kein Fall volles Root-Recht.
@esp8266
Nein, das hängt mit mount-Optionen zusammen. Ich schau mal ob ich da gleich einen PR zu mache.
Muss noch was tüfteln. -
@esp8266
Nein, das hängt mit mount-Optionen zusammen. Ich schau mal ob ich da gleich einen PR zu mache.
Muss noch was tüfteln.@thomas-braun , Ok. Dann wäre das aber nur unter Cifs. Denn NFS macht keine Probleme.
Mit Cifs hatte ich auch diverse Probs bei E2 Receivern. Darum arbeite ich nur mit NFS und hat wesentlich mehr Durchsatz.Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@thomas-braun , Ok. Dann wäre das aber nur unter Cifs. Denn NFS macht keine Probleme.
Mit Cifs hatte ich auch diverse Probs bei E2 Receivern. Darum arbeite ich nur mit NFS und hat wesentlich mehr Durchsatz.Ja, wenn es geht sollte man im Linux-Umfeld auch mit NFS operieren.
-
@thomas-braun , Ok. Dann wäre das aber nur unter Cifs. Denn NFS macht keine Probleme.
Mit Cifs hatte ich auch diverse Probs bei E2 Receivern. Darum arbeite ich nur mit NFS und hat wesentlich mehr Durchsatz.https://github.com/simatec/ioBroker.backitup/issues/819
und
https://github.com/simatec/ioBroker.backitup/pull/820
und
https://github.com/simatec/ioBroker.backitup/pull/821Bei mir gehören die Dateien jetzt fein dem iobroker:iobroker und nicht mehr dem doofen root:
echad@chet:~ $ ls -lA /opt/iobroker/backups/ total 144736 -rwxrwxrwx 1 iobroker iobroker 3377 Dec 10 03:42 historyDB_2022_12_10-03_42_32_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 3275 Dec 10 16:34 historyDB_2022_12_10-16_34_09_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 3275 Dec 10 16:37 historyDB_2022_12_10-16_37_41_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 3275 Dec 10 17:09 historyDB_2022_12_10-17_09_53_chet_backupiobroker.tar.gz -rwxrwxrwx 1 iobroker iobroker 3104 Dec 11 03:42 historyDB_2022_12_11-03_42_32_chet_backupiobroker.tar.gz -
Wenn da mal nicht mit sudo zuviel gehandhabt wurde. Ich habe auch schon einige Installationen hinter mir, aber irgendwelche Probleme mit Berechtigungen hatte ich so nie. Wenn es mal ein Problem gab, habe ich den Fixer drüber laufen lassen und gut war. Sudo nutzt man nur ausserhalb von IOB und in gar kein Fall volles Root-Recht.
@esp8266 sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
Wenn da mal nicht mit sudo zuviel gehandhabt wurde. Ich habe auch schon einige Installationen hinter mir, aber irgendwelche Probleme mit Berechtigungen hatte ich so nie. Wenn es mal ein Problem gab, habe ich den Fixer drüber laufen lassen und gut war. Sudo nutzt man nur ausserhalb von IOB und in gar kein Fall volles Root-Recht.
Weswegen man dafür Negativ bewertet wird, ist mir absolut Suspekt. Wenn es mal nötig wäre wird überhaupt nicht bewertet. Manche scheinen nicht mal zu wissen, was diese Funktion zu bedeuten hat. So nach dem Motto, mal ausprobieren was das ist....
Jedenfalls Danke für die negative Bewertung. Macht weiter so....Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@esp8266 sagte in zigbee funktioniert nicht mehr nach update auf bullseye:
Wenn da mal nicht mit sudo zuviel gehandhabt wurde. Ich habe auch schon einige Installationen hinter mir, aber irgendwelche Probleme mit Berechtigungen hatte ich so nie. Wenn es mal ein Problem gab, habe ich den Fixer drüber laufen lassen und gut war. Sudo nutzt man nur ausserhalb von IOB und in gar kein Fall volles Root-Recht.
Weswegen man dafür Negativ bewertet wird, ist mir absolut Suspekt. Wenn es mal nötig wäre wird überhaupt nicht bewertet. Manche scheinen nicht mal zu wissen, was diese Funktion zu bedeuten hat. So nach dem Motto, mal ausprobieren was das ist....
Jedenfalls Danke für die negative Bewertung. Macht weiter so....@esp8266 ich vermute mal, dass derjenige beim Scrollen am Handy/Tablet unabsichtlich auf den Downvote gekommen ist.
Ist hier schon öfters vorgekommen.
Support us
544
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge