[Gelöst]zigbee funktioniert nicht mehr nach upd auf bullseye

[Thomas Braun]

@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=0777

darf das keine Rolle spielen. Da darf dann Hinz und Kunz alles, egal welchem user oder group die Datei gehört.

[skinni]

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

@skinni

Ich würde behaupten, dein System ist schräg.

[skinni]

@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...

[Thomas Braun]

@skinni

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.gz

Wenn 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

[skinni]

@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.

[Thomas Braun]

@skinni

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.

[ESP8266]

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.

[Thomas Braun]

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

@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.

[Thomas Braun]

@esp8266

Ja, wenn es geht sollte man im Linux-Umfeld auch mit NFS operieren.

[Thomas Braun]

@esp8266 @skinni

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/821

Bei 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

Grothesk242 created this issue in simatec/ioBroker.backitup

closed Modify CIFS mount options #819

Grothesk242 created this issue in simatec/ioBroker.backitup

closed Update CIFS mount options #820

Grothesk242 created this issue in simatec/ioBroker.backitup

closed Update 01-mount.js #821

[ESP8266]

@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....

[Homoran]

@esp8266 ich vermute mal, dass derjenige beim Scrollen am Handy/Tablet unabsichtlich auf den Downvote gekommen ist.

Ist hier schon öfters vorgekommen.

[Thomas Braun]

@skinni

Hattest du das Problem mit der utime weiterhin?
backitup v2.5.10 hat jetzt einen Fix dafür drin.

[skinni]

@thomas-braun

Ja funktioniert jetzt

Started restore ...
[DEBUG] [zigbee] - Start Zigbee Restore ...
[DEBUG] [zigbee] - Filename for Restore: /opt/iobroker/backups/zigbee.0_2023_01_05-15_26_34_backupiobroker.tar.gz
[DEBUG] [zigbee] - zigbee tmp directory created: /opt/iobroker/backups/zigbee_0
[DEBUG] [zigbee] - old Zigbee database was successfully deleted
[DEBUG] [zigbee] - zigbee.0 stopped
[DEBUG] [zigbee] - Zigbee Database is successfully restored
[DEBUG] [zigbee] - Try deleting the Zigbee tmp directory
[DEBUG] [zigbee] - Zigbee tmp directory was successfully deleted
[DEBUG] [zigbee] - Zigbee Restore completed successfully
[EXIT] zigbee database restore done
[DEBUG] [zigbee] - zigbee.0 started