NEWS
[HowTo] ioBroker unter Docker auf Synology DiskStation
-
Da ist was ganz schräg bei dir gelaufen mit den
node_modules
/opt/iobroker/node_modules/iobroker.telegram/node_modules/socksv5/lib/auth/@eaDir
das Unter / Unter Verzeichiss und diese Datei gibt es nicht
@eaDir
Richtig wäre , es liegt aber alles im Ordner :
/opt/iobroker/node_modules/socksv5/
-
Es kann auch sein ... das auch andere Adapter betroffen sind , die du mal installieren willst !
Aber bei dieser Querinstallation habe ich auch kein Rat ... eher auf ein Neu Aufsetzen . -
@Glasfaser sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Es kann auch sein ... das auch andere Adapter betroffen sind , die du mal installieren willst !
Aber bei dieser Querinstallation habe ich auch kein Rat ... eher auf ein Neu Aufsetzen .also ich habe den Container jetzt neuaufgesetzt und bekomme bei der Installation des Telegram-Adapters nun folgende Fehlermeldung:
$ ./iobroker add telegram --host iobroker-docker NPM version: 6.14.8 npm install iobroker.telegram@1.5.9 --loglevel error --prefix "/opt/iobroker" (System call) npm ERR! code EINVALIDPACKAGENAME npm ERR! Invalid package name "@eaDir/.bin@SynoResource": name can only contain URL-friendly characters npm ERR! A complete log of this run can be found in:npm ERR! /opt/iobroker/.npm/_logs/2020-10-20T18_09_26_768Z-debug.log ERROR: host.iobroker-docker Cannot install iobroker.telegram@1.5.9: 1 ERROR: process exited with code 25
und wieder der Verweis auf "@eaDir/.bin@SynoResource"
Muss ich eventuell eine ENVIRONMENT Variable bei der Erstellung des Containers mitgeben?
-
-
@mumurik sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
also ich habe den Container jetzt neuaufgesetzt
mit Backup eingespielt ??
altes Mount Verzeichniss genutzt ?? -
@Glasfaser sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Welche Synology
DS220+
Welche DSM Version
DSM 6.2.3-25426 Update 2
Über Portainer erstellt
Ja
über die Synology Docker Oberfläche erstellt
nein
Fertiges Docker compose
ja, buanet/iobroker:latest
-
@Glasfaser
wegen@eaDir
google spuckt dazu einiges aus.
Beschreibung z.B. hierhttps://blog.andreas-schreiner.de/2019/03/18/synology-eadir-verzeichnisse-finden-und-loeschen/
EDIT: ob einfach löschen richtig ist, kann ich aber nicht sagen
-
Ja ... Danke , habe ich gestern schon danach gesucht .
Aber die Frage ist , wie kommt das in ioBroker rein !
.... auch bei der jetzigen Neuinstallation von Ihm .
-
-
@Glasfaser sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Aber die Frage ist , wie kommt das in ioBroker rein !
vielleicht indexiert er den Ordner ? (die Ordner kann man ja selbst angeben)
Zitat von der verlinkten Seite:
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.
-
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. -
@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...
-
-
@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é -
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! -
@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 ...
War auch ein blöder Fehler am Anfang bis man darauf kommt !
-
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...
-
@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
-
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.
-
@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 startBitte, 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é