[HowTo] ioBroker unter Docker auf Synology DiskStation

In der Regel ist der Index Service dafür verantwortlich, solche Dateien/Ordner zu verwalten. Wird der Shared Folder per SMB verbunden, sind die Ordner nicht sichtbar. Wird der Shared Folder per NFS oder AFS verbunden, sind die Ordner zu sehen und sind teilweise sehr störend.

Glasfaser

@dslraser

Ich würde es eher so machen ..
Synology komplett neu starten und dann den Container neu anlegen .
Da muss etwas bei der Synology sein .... anders kann ich mir es nicht vorstellen .
Also mit dem ioBroker Image ( Container ) hat es weniger zu tun .
Bin auch am Ende ... weiter weiß ich auch nicht , was es sein kann.

dslraser

@Glasfaser
Hier schreibt auch Jemand wie diese Verzeichnisse zu Stande kommen.

https://www.markus-gerber.ch/2014/07/eadir-auf-synology-nas/

Aber wie gesagt, helfen kann ich da auch nicht...

Glasfaser

@dslraser

Danke für deine Tipps ( wie immer ;) ) ....
Ich habe kein Rat dazu ..... aber das ist die Entscheidung von @mumurik ob er was löscht .

andre

@mumurik Ich hab jetzt zwar nicht alles gelesen, aber die "@eaDir" Verzeichnisse kommen wohl von der Medienindizierung. Hast du mal geschaut ob da bei dir vielleicht was aktiviert ist? Kann mir schon vorstellen, dass es ggf. ungünstig ist, wenn die DS den Ordner indiziert in dem dein iobroker liegt und dann dort vielleicht auch noch Verzeichnisse anlegt...

Im Zweifel würde ich mal probieren für den Ordner /opt/iobroker auf der DS einen anderen Pfad zu nehmen. Dann ne frische Container Installation machen und über restore ein Backup einspielen.

MfG,
André

mumurik

Also, Indizierung war für den iobroker-Verzeichnis nicht eingeschaltet, aber die "@eaDir" Verzeichnisse wurden wohl nach der Migration automatisch angelegt (ich hatte vor kurzem eine Migration von DS213j zu DS220+).

Ich habe jetzt alle "@eaDir" Verzeichnisse manuell gelöscht und den Container neuangelegt -> keine Probleme mehr mit der Installation des Adapters!

@Glasfaser @dslraser @andre
Vielen lieben Dank an alle für die hilfreichen Tipps!

Glasfaser

@mumurik sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

wurden wohl nach der Migration automatisch angelegt
ich hatte vor kurzem eine Migration von DS213j zu DS220+

dann passt das auch zu diesem Link @eaDir auf dem Synology NAS

Zitat :

Nach dem Zurückspielen eines Backups auf meinem Synology-NAS stellte ich fest, dass dieses, ohne mich zu fragen, überall seine @eaDir Verzeichnisse eingefügt hat.

keine Probleme mehr mit der Installation des Adapters!

Schön das es jetzt geht ... :face_with_thermometer: :cold_sweat:

War auch ein blöder Fehler am Anfang bis man darauf kommt !

Satsh

Leider habe ich ein Problem mit dem Upgrade von 4.2.0 auf 5.0.0.

Habe mittels BackItUp ein Minimal-Backup erzeugt, den Container heruntergefahren, den Container gecloned und dabei das Image mit neuem Tag gepulled, sowie den Mount auf ein neues Verzeichnis umgebogen. In das root des neuen Verzeichnisses habe ich dann das backup gelegt und den Container hochgefahren.

Er erkennt zwar das Backup und versucht es auch einzuspielen, bricht aber ohne nennenswerte Meldungen ab, lediglich das restore.log enthält einen Fehler - den finde ich zwar im Forum, aber keiner der Hinweise scheint irgendwie zu passen.

Docker Log:

------------------------------------------------------------,
---------------     2020-10-26 15:06:17      ---------------,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----       Welcome to your ioBroker-container!        -----,
-----          Startupscript is now running.           -----,
-----                Please be patient!                -----,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----              Debugging information               -----,
-----                                                  -----,
-----                      System                      -----,
-----               arch:      x86_64                  -----,
-----                                                  -----,
-----                     Versions                     -----,
-----               image:     v5.0.0                  -----,
-----               node:      v12.19.0                -----,
-----               npm:       6.14.8                  -----,
-----                                                  -----,
-----                       ENV                        -----,
-----               PACKAGES:  vi                      -----,
-----               SETGID:    1000                    -----,
-----               SETUID:    1000                    -----,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----         Step 1 of 5: Preparing container         -----,
------------------------------------------------------------,
 ,
Installing additional packages is set by ENV.,
The following packages will be installed: vi...,
E: Paket vi kann nicht gefunden werden.,
Done.,
 ,
------------------------------------------------------------,
-----   Step 2 of 5: Detecting ioBroker installation   -----,
------------------------------------------------------------,
 ,
ioBroker backup file detected in /opt/iobroker. Restoring ioBroker...,
Done.,
 ,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!,
!!!!!                             IMPORTANT NOTE                             !!!!!,
!!!!!        The sartup script restored iobroker from a backup file.         !!!!!,
!!!!! Check /opt/iobroker/log/restore.log to see if restore was successful.  !!!!!,
!!!!! When ioBroker now starts it will reinstall all Adapters automatically. !!!!!,
!!!!!         This might be take a looooong time! Please be patient!         !!!!!,
!!!!!  You can view installation process by taking a look at ioBroker log.   !!!!!,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!,
 ,
------------------------------------------------------------,
-----   Step 3 of 5: Checking ioBroker installation    -----,
------------------------------------------------------------,
 ,
(Re)Setting folder permissions (This might take a while! Please be patient!)...,
Done.,
 ,
Fixing "sudo-bug" by replacing sudo in iobroker with gosu...,
Done.,
 ,
Looks like this is a new and empty installation of ioBroker.,
Hostname needs to be updated to  iobroker.fritz.box...,
The host for instance "system.adapter.admin.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
The host for instance "system.adapter.discovery.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
The host for instance "system.adapter.info.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
Done.,
 ,
------------------------------------------------------------,
-----      Step 4 of 5: Applying special settings      -----,
------------------------------------------------------------,
 ,
Some adapters have special requirements/ settings which can be activated by the use of environment variables.,
For more information take a look at readme.md on Github!,
 ,
------------------------------------------------------------,
-----          Step 5 of 5: ioBroker startup           -----,
------------------------------------------------------------,
 ,
Starting ioBroker...,
 ,
host.iobroker.fritz.box check instance "system.adapter.admin.0" for host "iobroker.fritz.box",
host.iobroker.fritz.box check instance "system.adapter.discovery.0" for host "iobroker.fritz.box",
host.iobroker.fritz.box check instance "system.adapter.info.0" for host "iobroker.fritz.box",
Send diag info: {"uuid":"7abd3182-d399-f7bd-da19-9550d8babede","language":"","country":"","hosts":[{"version":"3.1.6","platform":"Javascript/Node.js","type":"linux"}],"node":"v12.19.0","arch":"x64","adapters":{"admin":{"version":"4.0.10","platform":"Javascript/Node.js"},"discovery":{"version":"2.3.7","platform":"Javascript/Node.js"},"info":{"version":"1.7.2","platform":"Javascript/Node.js"}},"statesType":"file","objectsType":"file","model":"Intel(R) Celeron(R) CPU J3355 @ 2.00GHz","cpus":2,"mem":10282930176,"ostype":"Linux","city":""},
hash changed or no sources cached => force download of new sources,

Restore.log:

host.iobroker.fritz.box Using backup file iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz
host.iobroker.fritz.box Cannot find extracted file from file "/opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/backup.json"
 Cannot save /opt/iobroker/iobroker-data/states.json: Error: EACCES: permission denied, open '/opt/iobroker/iobroker-data/states.json.bak'

Ich habe auch schon versucht ioBroker nackt als 5.0.0 hochzufahren, BackItUp zu installieren und darüber dann zu recovern - das bringt leider auch kein zählbares Ergebnis.

Habe ich irgendwo ein Brett vor dem Kopf? Ist das ein bekanntes Problem? Ich finde es gerade etwas erschreckend, dass scheinbar meine Backups bei einem Fresh Install gar nicht funktionieren...

Glasfaser

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Ich habe auch schon versucht ioBroker nackt als 5.0.0 hochzufahren,

dann den Ordner erstellen

mkdir /opt/iobroker/backups

dort dein Backup rein , dann

pkill -u iobroker
iobroker restore iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz
iobroker start

eventuell wenn es danach nicht geht

pkill -u iobroker
iobroker host this
iobroker start

Satsh

@Glasfaser

Das bin ich zwischendurch auch schon selber angegangen und es scheint auch mit leichteren Hopsalas funktioniert zu haben.
Hat erst mal ein bisschen gedauert, bis ich gemerkt habe, dass unter 5.0.0 "pkill io" gleich den ganzen Container killed, dachte immer irgendwas wäre jetzt ganz kaputt... Zum "Glück" liefen ja nur drei Instanzen, die ich dann von Hand gekillt habe.

Der Restore hat mit einigem Meckern im Log funktioniert, aber das waren aus meiner Sicht vernachlässigbare Fehler. Beim Versuch die Instanzen zu starten, hat er erwartungsgemäß gemeckert, dass die Instanz nicht da wäre und er den Adapter jetzt installiert. Dabei haben einige Adapter gemeckert, dass das Nachinstallieren einiger Libs fehlgeschlagen wäre.
Die Instanzen wurden dann aber danach doch nicht gestartet. Bis auf admin.0 waren alle Instanzen stopped. Ich habe diese dann von Hand nacheinander gestartet und immer ein bisschen gewartet. Dann habe ich den ioBroker mal 30 Minuten in Ruhe gelassen und dann denn Container restartet um zu schauen, ob auch alles wieder sauber hoch kommt.

Bis dato sieht alles gut aus. Auch meine größte Angst, dass ioBroker mal wieder meine History Datenpunkte gekilled hat, hat sich nicht bestätigt. Nach dem Start des InfluxDB Adapters waren alle Datenpunkte wieder so im Logging, wie es sein sollte.

Würde sagen: Operation geglückt.

Aber wieso funktioniert der Restore beim FirstStart nicht? Gibt es da irgendwelche Hinweise? Bin auch durchaus bereit hier noch zu unterstützen und Sachen zu debuggen.

andre

@Glasfaser sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

dort dein Backup rein , dann
pkill -u iobroker iobroker restore iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz iobroker start
eventuell wenn es danach nicht geht
pkill -u iobroker iobroker host this iobroker start

Bitte, bitte kein "iobroker start" im Container! Den Container immer komplett neu starten, damit das Startscript durch läuft und den ioBroker selbst startet!
https://smarthome.buanet.de/2019/05/iobroker-docker-image-steuerung-per-kommandozeile/

MfG,
André

andre

@Satsh Soweit alles richtig gemacht.

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Aber wieso funktioniert der Restore beim FirstStart nicht? Gibt es da irgendwelche Hinweise? Bin auch durchaus bereit hier noch zu unterstützen und Sachen zu debuggen.

Der Restore funktioniert aufgrund eines Zugriffsproblems nicht. Kurzum, irgendwas mit den Berechtigungen stimmt da nicht.

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Cannot save /opt/iobroker/iobroker-data/states.json: Error: EACCES: permission denied, open '/opt/iobroker/iobroker-data/states.json.bak'

Das ist der Übeltäter. Habe in letzter Zeit vermehrt Anfragen dazu. Habe noch nicht rausgefunden was da los ist und ob sich da irgendwo etwas verändert hat, auf das ich im image vielleicht reagieren muss...
folgendes würde mich in deinem Fall interessieren:

Nutzt du eine DiskStation als Docker Host?
Wie und wo legst du das Verzeichnis an, dass du für /opt/iobroker verwendest?
Mit welchem User auf der DS arbeitest du (also aus Sicht der Berechtigungen)?
Wie kopierst du das Backupfile?
Irgendwelse Besonderheiten/ Hindernisse vor dem ersten Start des Containers?

MfG,
André

Satsh

@andre

Ja, ioBroker läuft direkt auf meiner DS
Ich habe innerhalb der DS einen gemeinsamen Ordner /Docker, unter dem ich die einzelnen Mountpoints anlege, damit sie ins Backup laufen. Für ioBroker mache ich einen lokalen Bind auf /volume1/Docker/iobroker (Beispiel), ich nutze für ioBroker kein Volume im Docker.
Ohne User, da lokaler Bind.
Ich habe zwei Wege probiert, da ich von dem "Kopierfehler über Windows" gelesen habe: 1. Copy&Paste innerhalb der DS (CMD+C,CMD+V) 2. Download von der DS, Upload auf die DS
Ich clone den alten ioBroker Container und führe danach folgende Änderungen durch:

Bind auf neues, leeres Verzeichnes (damit ich im Notfall das alte Verzeichnis noch mit dem alten Container als Fallback wieder hochfahren kann)
Pull des neues Image (hier 5.0.0)
Kopieren des letzten Backups in das root des neuen Verzeichnisses

Irritierend ist ja, dass das Verzeichnis komplett leer ist und damit ja keine Verzeichnisse mit falschen Berechtigungen existieren. Alles was erzeugt wird, wird von ioBroker erzeugt. Und entpacken kann er das Backup ja scheinbar und legt damit auch Verzeichnisse an. Und danach hat er ein Problem ein selbst angelegtes File zu lesen? Das klingt schon sehr seltsam...

Ich weiß nur leider nicht wo ich zum Debuggen dazwischenfunken kann. Wo ist denn das Script, was das Backup dabei behandelt? Dann schaue ich mal drüber...

Satsh

@andre

Ich glaube ich habe die Ursache gefunden:

root@iobroker:~# tar tvf /opt/initial_iobroker.tar | grep root.root
drwxr-xr-x root/root              0 2020-10-19 14:15 opt/iobroker/node_modules/iobroker.js-controller/tmp/
-rw-r--r-- root/root           28844 2020-10-19 14:15 opt/iobroker/iobroker-data/backup-objects/2020-10-19_12-15_objects.json.gz
-rw-r--r-- root/root              22 2020-10-19 14:15 opt/iobroker/iobroker-data/backup-objects/2020-10-19_12-15_states.json.gz
-rw-r--r-- root/root               2 2020-10-19 14:15 opt/iobroker/iobroker-data/states.json.bak
-rw-rw-r-- root/root              13 2020-10-19 14:15 opt/iobroker/.install_host

Es gibt im initial_iobroker.tar einige Dateien, die root.root gehören - insbesondere auch die states.json.bak - die der iobroker beim restore 0 wahrescheinlich überschreiben möchte - aber wahrscheinlich nicht kann, weil (Vermutung!) iobroker selber einen priviledge drop macht?

S

andre

@Satsh Hab mir das gerade mal genauer angeschaut. In der Tat gibt es da Probleme mit den Berechtigungen.
Habe das jetzt im Startupscript beim Restore abgefangen. Beim ersten Test hat das wunderbar funktioniert. Warum es aber jetzt plötzlich zu solch einem Fehler kommt ist mir ein Rätsel. Mein Letzter Restore am Livesystem hat tadellos funktioniert...

Achso, aktuell ist der Fix noch nicht in der Beta enthalten. Muss noch zwei andere Sachen prüfen (und Dokumentieren) und mache dann eine neue Beta-Version.

MfG,
André

Satsh

@andre
Blöde Frage: aber was muss man da groß fixen - außer die Files im initial_iobroker.tar mit den korrekten user/group Rechten zu versehen? Oder übersehe ich etwas und die Ursache war noch eine Andere?

Ich denke es kommt auch darauf an, wie man den Mount einbindet. Bei einem nfs mit all-squash oder einem CIFS mit fixed user credentials würde das Problem nicht auftreten denke ich, da hier der User vom Transportprotokol festgetackert wird - egal welche Berechtigungen das File eigentlich hatte.

Community Forum

NEWS

[HowTo] ioBroker unter Docker auf Synology DiskStation

Support us

856

32.4k

81.4k

1.3m