Klingt wie hier schon beschrieben -> https://forum.iobroker.net/viewtopic.php?f=8&t=17177
Habe die Tage eine frische ioBroker Installation auf einem Raspi aufgesetzt (Admin 3.5.10) und der Fehler besteht weiterhin.
Edit: gerade den Workarround mit der neuen Gruppe (analog Admingruppe) versucht, funktioniert bestens.
Im Grunde reicht ein einfacher FTP-Server (google mal Raspberry FTP-Server). Es gibt je nach Anforderung und useability verschiedene Lösungen.
Ich persönlich nutze Nextcloud auf einem NUC (da laufen auch noch andere DIenste drauf). Das wird aber je nach Konfig auf dem PI dann doch alles ein bisschen eng…
Zudem sollte man auch beachten, dass manche SD Karten den Dauerbetrieb nicht gut verkraften. Sie gehen gerne mal kaputt, sprich man sollte persistente Daten auf einem externen Speicher am PI anbinden.
Das hat jetzt aber nichts mehr mit ioBroker zu tun 
Ich würde erst ioBroker stoppen und dann das OS updaten. Danach mit iobroker update nach verfügbaren Aktualisierungen prüfen lassen und mit iobroker upgrade adapter die jeweilige Aktualisierung durchführen. Sie auch http://www.iobroker.net/docu/?page_id=3074&lang=de
Ich Depp… Ja klar, hatte das Repo auf latest gestellt gehabt.
Habe eben einen neuen Container mit einer firschen Installation gestartet und direkt auf Admin 3.5.10 geupdatet. Dann einen neuen Benutzer angelegt, diesen in die Gruppe "Administrator" aufgenommen und im Admin.0 https und die Authentifizierung aktivert. Nach Eingabe der neuen Anmeldedaten kommt wieder die Meldung "Permission error":
Habe gestern IoBroker komplett neu in einem Ubuntucontainer installiert und exakt das gleiche Problem. Https und Authentifizierung im Admin.0 aktiviert, login mit dem Benutzer admin klappt problemlos. Dann einen eigenen Benutzer angelegt (nur Kleinbuchstaben), ihn in die Admingruppe gepackt und nach der Anmeldung erhalte ich genau die selbe "Permission Error" Meldung. Auch die Log-Einträge sind identisch.
Bevor ich IoBroker im Container installiert hatte, lief er nativ auf dem PI, dort hatte ich dieses Problem mit einem neuen Benutzer nicht. Um auszuschließen, dass es am Container liegt, hatte ich ioBroker dann nochmal nativ auf dem PI installiert, siehe da selber Fehler…
Was mir aufgefallen ist, dass ich aktuell eine etwas ältere ioBroker.admin Version habe. Am Anfang war es 3.4.9 (hatte zwischenzeitlich per iobroker upgrade-self geupdatet) als ich ioBroker das erste mal nativ auf dem PI installiert hatte. Jetzt bekomme ich "nur" noch die Version 3.4.7 zur Verfügung, auch nach Update via Konsole.
@dwm:
Versuch mal, das komplette Netzwerk auf den host zu mappen (docker start mit dem parameter –network host) `
Volltreffer!! Damit klappts jetzt wie es sein soll.
Habe das Ganze jetzt mal auf dem PI zum Test aufgebaut, lasse es eine Weile laufen und wenns stabil bleibt zieh ich alles auf den Nuc um.
Vielen Dank für den Tip! 
Bin aktuell auch dabei meinen NUC neu aufzusetzen und möchte dabei alles komplett in Container packen. Da ich es allerdings nicht geschafft habe, eins der IoBroker Images aus dem Docker Hub ans laufen zubringen, habe ich kurzerhand einen Ubuntucontainer gestartet und dort drin IoBroker installiert. Es läuft auch soweit alles, nur werden keine Wlan Geräte gefunden. Ich kann die Yeelights oder auch den LW12 manuell eintragen, diese lassen sich dann auch steuern, aber der Chromecast Adapter bietet mir diese Möglichkeit leider nicht… Ich vermute, es liegt an dem eigenen Netz was Docker aufspannt. Hat hier jemand IoBroker im Container laufen und findet seine lokalen Wlan-Geräte? Oder komm ich um ein Vlan nicht drum rum?
Raumfeld unterstützt ja nativ das Chromecast Protokoll.
Also sollte man sein Gerät problemlos darüber steuern können. ` Yep, funktioniert problemlos.
Ich streame auf meinen One S und die Soundbar diverse Radios, starte/stoppe und steuere die Lautstärke. Zusätzlich noch das ganze über den Google Home (Blockly + Chromecast Adapter).
Er kann die Geräte ja auch ohne ioBroker nativ über Chromecast steuern, die Lösung mit ioBroker gefällt mir aber besser, weil man dann eben nicht immer den Google Home oder die Teufel App zum steuern braucht
Das Problem ist gelöst (es war wie so oft ein Layer 8 Problem ;)), es hatte sich beim Weghook ein Leerzeichen eingeschlichen…
Jetzt funktioniert das Ganze genau so, wie ich das will. Habe bei der Gelegeheit auch gleich die beiden Skripte in eins gepackt, sonst wirds mit der Zeit unübersichtlich.
Hm, genau das will ich ja nicht (daher der Weg über Command), sonst leuchtet ja erst die zuletzt eingestellte Farbe und wechsel dann auf die neu gewählte, oder nicht?
Das Problem hängt mMn auch nicht direkt mit dem Wifilight Adapter zusammen, denn über vis funktioniert es ja wie es soll (an/aus, Farbwechsel und an mit gewünschter Farbe). Habe dort einfache Buttons angelegt die "IFTTT Value" mit den Werten setzten (so wie sie auch der Webhook setzt). Darum kann ich auch gerade nicht wirklich nachvollziehen, was hier das Problem ist :?:
