Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[simatec]

@ullrjo
In der Doku steht Schritt für Schritt beschrieben, wie Dropbox eingerichtet werden muss.

https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md#dropbox

[qqolli]

@haselchen

Hallo und danke. Die Einstellungen kannte ich bereits, mir geht es um die Einstellungen auf der NAS. Welche Einstellungen hast Du gewählt (s. unten)? Bekomme es noch nicht zum laufen

[haselchen]

@qqolli

Erstmal PCR Test , dann Arzt , dann bin ich für Dich da
Melde mich .

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

In der Doku steht Schritt für Schritt beschrieben, wie Dropbox eingerichtet werden muss.
https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md#dropbox

Hi, daran habe ich mich auch gehalten, im vorigen Jahr und jetzt auch, aber es hat sich anscheinend im Untergrund was geändert, im Webinterface für Apps in Dropbox sehe ich z.B. kein "Access token expiration"

Aber was mir jetzt aufgefallen ist, im Log steht eine Error-Meldung:

backitup.1	2022-03-18 09:07:30.979	error	(13336) Dropbox: "missing_scope/..."
backitup.1	2022-03-18 09:07:30.978	error	(13336) Dropbox: "missing_scope/..."
backitup.1	2022-03-18 09:07:30.585	error	(13336) [iobroker] chmod for Backup directory could not be completed: Error: EPERM: operation not permitted, chmod '/opt/iobroker/backups'Please run "iobroker fix"!!

Ist das "missing_scope/..." eine fehlerhafte Einstellung im Adapter oder in der Dropbox?
Die Meldung mit dem chmod verstehe ich nicht ganz, ein "iob fix" hat nichts gebracht, die Rechte der Files und Verzeichnisse in '/opt/iobroker/backups' sind aber '777' also keine Einschränkungen bei Zugriffen, wie ich glaube.

Und das ist noch die DEBUG-Ausgabe betreff Dropbox:

[DEBUG] [dropbox] - Dropbox: Copy iobroker_2022_03_18-09_07_30_backupiobroker.tar.gz...
[DEBUG] [dropbox] start with {"type":"storage","source":"local","debugging":true,"deleteOldBackup":true,"accessToken":"****","ownDir":false,"dir":"/Slave/","dirMinimal":"/backupDir/iobroker","ignoreErrors":false,"deleteBackupAfter":0}
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - Dropbox: Copy zigbee.0_2022_03_18-09_07_41_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - done

[simatec]

@diwoma sagte in Test Adapter Backitup v2.3.x:

im Webinterface für Apps in Dropbox sehe ich z.B. kein "Access token expiration"

Gibt es wohl nicht mehr.

Ich habe aber gerade nach der Step by Step Anleitung aus der Doku eine neue App erstellt und in Backitup eingerichtet.
Lief sofort und die Backups liegen in der Dropbox

Vielleicht erstellst du mal eine neue App und generiest den Token aber wirklich erst nachdem du alle Einstellungen korrekt gesetzt hast.

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

Ich habe aber gerade nach der Step by Step Anleitung aus der Doku eine neue App erstellt und in Backitup eingerichtet.
Lief sofort und die Backups liegen in der Dropbox
Vielleicht erstellst du mal eine neue App und generiest den Token aber wirklich erst nachdem du alle Einstellungen korrekt gesetzt hast.

Habe ich gemacht, neue App, alles eingestellt, Token generiert und geht trotzdem nicht.
Werde wohl am Slave auf Dropbox verzichten müssen?

[simatec]

@diwoma Ob Master oder Slave ist für Backitup egal.
Aber jetzt mal ne andere Frage… warum nimmst du nicht die APP vom Master? Brauchst doch nur einen Unterordner anlegen

[Siggi0904]

@simatec ich habe nun mysqldump über das Paket "mariadb-client-core-10.5" installiert.
Das ist das aktuell gültige Paket für Debian Bullseye. mysqldump verweist darin auf die Datei mariadbdump. Es ist also eigentlich alles bei Debian Bullseye auf MariaDB.

Der Backup-Lauf der MySQL-Datenbank lief auch sauber durch.
Was mir nur auffiel, dass die SQL-Datei im Archiv nicht benannt wird.
Im Archiv ist die Datei mit dem richtigen Inhalt vorhanden, hat nur keinen Namen und Endung.
Siehe:

Wo kann man im Backup-Adapter den Namen mitgeben?
Oder ist das ein genereller Bug, da auch die .sql Endung fehlt?

Danke.

[simatec]

@siggi0904 Das ist so gewollt ... Die Backudatei ist so korrekt und kann problemlos mit Backitup wiederhergestellt werden

[Siggi0904]

@simatec okay. Dank dir für die Info.

[diwoma]

@simatec
Das habe ich zuerst ja probiert, da hat es den Fehler dann gegeben.
Ich habe das dann auf eine geänderte API geschoben und gedacht, ich probiere es mit einer neuen App

[simatec]

@diwoma Ändere mal die Berechtigungen und speichere diese. Im Anschluss dann den Token neu generieren ... In meinen Test lief es immer ohne Probleme.

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

@diwoma Ändere mal die Berechtigungen und speichere diese. Im Anschluss dann den Token neu generieren ... In meinen Test lief es immer ohne Probleme.

Habe es gerade wieder probiert, ändert nichts am Ergebnis.
Was mich dabei irritiert, es wird kein Permission-Fehler gemeldet sondern ein Header-Fehler im Content-Type, so als würde die API kein gzip mehr wollen.

Die Sicherung auf mein Nas funktioniert, allerdings auch mit unerklärlichen Nebenerscheinungen, die kein Teil dieses Threads sein sollten.

[simatec]

@diwoma Auf Github der Api gab es dazu mal ein Issue.

https://github.com/adasq/dropbox-v2-api/issues/1131

neilyoung created this issue in adasq/dropbox-v2-api

closed Catching "missing_scope" #1131

[haselchen]

@qqolli

[qqolli]

@haselchen

Hallo,

hatte es bereits mit diesen Einstellungen hinbekommen, aber trotzdem vielen Dank.

[simatec]

@simatec ja da steht im Prinzip das selbe drin.
Erst die Rechte setzen, dann einen neuen Token generieren.

[haselchen]

@qqolli

Für die User hier mit vielleicht dem gleichen Problem, schildere mal bitte Deine Lösung.

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

@simatec ja da steht im Prinzip das selbe drin.
Erst die Rechte setzen, dann einen neuen Token generieren.

OK, ich habe nun folgendes probiert:

• Reinstallation des Backup-Adapters auf dem Slave
• Erstellen einer neuen App auf Dropbox, einstellen der Rechte, danach Token generiert
• Verwenden der funktionierenden App vom Master

Immer das gleiche Ergebnis:

Started iobroker ...
[DEBUG] [iobroker] - host.pi-broker 8470 states saved

[DEBUG] [iobroker] - host.pi-broker 9165 objects saved

[DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2022_03_21-08_01_19_backupiobroker.tar.gz

[DEBUG] [iobroker] - done
[DEBUG] [zigbee] - found zigbee database: zigbee.0
[DEBUG] [zigbee] - done
[DEBUG] [dropbox] - Dropbox: Copy iobroker_2022_03_21-08_01_19_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - Dropbox: Copy zigbee.0_2022_03_21-08_01_30_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - done
[DEBUG] [clean] - done
[DEBUG] [historyHTML] - new history html values created
[DEBUG] [historyHTML] - done
[DEBUG] [historyJSON] - new history json values created
[DEBUG] [historyJSON] - done
[EXIT] 0

Wenn es bei den anderen funktioniert, muss es wohl einen Fehler in meiner Installation sein.
Ich lasse die Dropbox auf dem Slave mal aus und speichere es auf dem Nas.

[simatec]

@diwoma Kannst du mir mal zeigen, was du für einen Fehlerlog bei Start der Slave Instanz bekommst.
Ich bin gerade mit den Entwicklern der dropbox Api am schreiben.

Hier wurde etwas umgestellt, was irgendwie murks ist. Der Token ist bei neuen Apps nur noch "short_live".
Das bedeutet aktuell hat der Token nur noch 4 Stunden Gültigkeit.

Ich bin auf Lösungssuche ... aber das dauert noch.

Wenn du aber erstmal schnell die Lösung benötigst, dann sichere dir mal aus deinem Master die Einstellungen (Pfeile oben Links in der Konfiguration)
Danach kannst du die json lokal öffnen und findest dort den API-Token deines Masters.

Den kannst du dann im Slave eintragen und nutzt damit die gleiche APP mit dem Token