Container startet nicht mehr richtig nach Umzug auf Backup-NAS

[Marko1976]

Hallo, ich musste meinen Fhem-Server und den damit verbundenen Docker-Container samt Container-Station temporär auf mein Backup-NAs auslagern, da ich das Primär-NAS komplett neu aufsetzen musste.

Doch leider lässt sich der Container auf dem Backup-NAS nicht starten.

Hier mal ein Auszug aus dem Start-Log:

Code Auswählen Erweitern

INFO: Preparing initial container setup
INFO: Updating existing FHEM installation in /opt/fhem
INFO:   Patching fhem.cfg Logfile configuration
INFO: Initial container setup done
INFO: Preparing user environment
INFO: Creating group 'fhem' with GID 6061
INFO: Enforcing GID for group 'bluetooth' to 6001
INFO: Creating user 'fhem' with UID 6061
INFO: Creating log directory /opt/fhem/log
INFO: Creating PID directory /opt/fhem/log
INFO: Enforcing user and group ownership for /opt/fhem to fhem:fhem
INFO: Enforcing file and directory permissions for /opt/fhem
INFO: Correcting group ownership for /dev/tty*
INFO: Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002
INFO: Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003
INFO: Updating /etc/sudoers.d/fhem-docker
INFO: Patching /etc/hosts file with DOCKER_HOST and DOCKER_GW'
INFO: Adding 192.168.178.1      host.docker.internal to /etc/hosts
192.168.178.1   host.docker.internal
INFO: Adding 192.168.178.1      gateway.docker.internal to /etc/hosts
192.168.178.1   gateway.docker.internal
INFO: Pre-authorizing SSH to Docker host for user 'fhem'
INFO: Updating SSH key pinning and SSH client permissions for user 'fhem'
INFO: Preparing user environment done
INFO: Starting FHEM
2025.12.29 22:28:03 3: logfile is readonly, it is set in the FHEM_GLOBALATTR environment
2025.12.29 22:28:05 1: PERL WARNING: "my" variable $string masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 244.
2025.12.29 22:28:05.034 3: pidfilename is readonly, it is set in the FHEM_GLOBALATTR environment
2025.12.29 22:28:08.076 0: [echodevice_Define] load ECHO Devicename=Echo_Schlafzimmer Devicetype=A2H4LV5GIZ1JFT Devicemodel=Echo Dot Gen4 with Clock
2025.12.29 22:28:08.079 0: [echodevice_Define] load ECHO Devicename=Echo_Wohnzimmer Devicetype=A2U21SRK4QGSE1 Devicemodel=Echo Dot Gen4
2025.12.29 22:28:54.175 0: [echodevice_Define] load ECHO Devicename=Echo_Kueche Devicetype=ASQZWP4GPYUT7 Devicemodel=Echo Plus 2
2025.12.29 22:28:54.180 0: [echodevice_Define] load ECHO Devicename=ECHO_G0G2HN033146003G Devicetype=ASQZWP4GPYUT7 Devicemodel=Echo Plus 2
ERROR: Fatal: No message from FHEM since 60 seconds that server has started.
INFO: Stopping container. Bye!
INFO: Preparing user environment
INFO: Creating group 'fhem' with GID 6061
INFO: Enforcing GID for group 'bluetooth' to 6001
INFO: Creating user 'fhem' with UID 6061
INFO: Creating log directory /opt/fhem/log
INFO: Creating PID directory /opt/fhem/log
INFO: Enforcing user and group ownership for /opt/fhem to fhem:fhem
INFO: Enforcing file and directory permissions for /opt/fhem
Relevant ist wohl diese Zeile:

Code Auswählen Erweitern

ERROR: Fatal: No message from FHEM since 60 seconds that server has started.
Doch mir ist nicht klar wie es dazu kommt. Hat jemand eine Idee wie ich es ans Laufen bringen kann oder wo das Problem liegt?
Übrigens zeigt sich gleiches Verhalten wenn ich versuche den alten Conatiner auf dem neu aufgesetzten Primär-NAS einzufügen.

[passibe]

Zeig mal dein compose file oder den docker run-Befehl. Berechtigungen usw. sind alle identisch? Hast du nicht vergessen, irgendwelche Dateien zu kopieren?

Ich erinnere mich dunkel, dass wir sowas schon einmal irgendwo hatten (evtl. mal suchen), irgendwie vielleicht auch im Zusammenhang mit dieser Meldung:

2025.12.29 22:28:05.034 3: pidfilename is readonly, it is set in the FHEM_GLOBALATTR environment

Aber nicht mehr sicher, ob das tatsächlich ein Problem war oder nicht oder was da letztlich die Lösung ist/war.

[Marko1976]

Zeig mal dein compose file oder den docker run-Befehl.

Gerne wenn du mir sagst wie.
Auf diesem Gebiet bin ich eigentlich absoluter Laie und mache nur das was man mir sagt.

Allerdings würde da auch eine andere Frage greifen:
Im Laufe der Jahre habe ich natürlich einige Dinge auf der Konsole nachinstalliert, zb. für Alexa etc.. Die sind in dem neuen Kontainer jetzt natürlich nicht drin.
Gibt es eine Möglichkeit anhand des alten Containers rauszufinden was da alles nachinstalliert wurde per Console oder vielleicht sogar mit welchen Befehlen genau?

[Wernieman]

Nein ..und genau aus dem Grunde installiert man eigentlich nicht in einem Container direkt nach, sondern bei der Containererstellung. Container sind eben keine VMs

Wo hast Du eigentlich die persistenten Daten liegen? Hast Du auch die kopiert und mit den richtigen Berechtigungen?

[Marko1976]

Nein ..und genau aus dem Grunde installiert man eigentlich nicht in einem Container direkt nach, sondern bei der Containererstellung. Container sind eben keine VMs

Na ich weiß nicht wo du deine Conatiner findest, aber beispielsweise der Fhem-Container um den es hier eben geht ist ein reines Basismodell und soll bewusst nach den Bedürfnissen angepasst werden. Zum Beispiel fehlt die Alexa-Funktionalität (also nodejs) oder naderes. Und da so ein Gebilde wie Fhem mit der Zeit wächst wirst du eh keinen Container finden der im Vorfeld alle Möglichkeiten abdeckt.

Wo hast Du eigentlich die persistenten Daten liegen? Hast Du auch die kopiert und mit den richtigen Berechtigungen?

Ich weiß jetzt nicht was du mit persistent meinst, aber wenn du die eigentlichen Containerdaten mit den ganzen Einstellungen meinst, das liegt auf einem Serverfreigabelaufwerk und ist unabhängig von der Container-Station.

[CoolTux]

Sorry Marko, aber Dein Gedanke zum Thema Container und ganz speziell zum Thema Anwendungscontainer ist leider falsch.
Container sind in sich geschlossene Systeme, das einzige was da noch rein kommt sind Systeminformationen (Log Files und sowas) und Nutzdaten. Nutzdaten können wichtig sein oder eben nicht. Wenn sie wichtig sind dann bindet man an einen Container ein persistent Volume an. Das Volume kann auf dem Docker Host liegen und durch ein Verzeichnis abgebildet werden oder kann am Ende auf einem Netzwerkhost liegen.

Der fhem Container ist so aufgebaut das eigentlich das ganze fhem Verzeichnis, also das root von fhem auf einem Volume liegen sollte. So ist die Idee und am Ende bleibt halt im Container das System.

Fehlt Dir was beim System dann baut man das Container Image eben selbst.

Alles was Du per apt im Container "installiert" hast ist beim löschen des Containers weg. Container sind wegwerfobjekte.

Wenn Dein alter Container gelöscht ist dann ist alles weg was direkt im Container war, also nicht in ein Volume gespeichert wurde.



Euch allen ein gesundes neues Jahr.

[Wernieman]

Wenn Dein alter Container gelöscht ist dann ist alles weg was direkt im Container war, also nicht in ein Volume gespeichert wurde.

Genau das meinte ich mit persistente Daten. Also entweder per "mount" in ein Docker-Volumen oder in ein Verzeichnis. Bei Single Docker-Systemen würde ich für Anfänger die Speicherung in Verzeichnisse Empfehlen. Aber DAS ist nur meine Meinung.

Ein Container (und auch der FHEM Container ist so) soll eigentlich fertig sein, eventuell wird beim ersten Starten AUTOMATISCH Sachen nachinstalliert. Jede Manuelle Nachinstallation ist, wie CoolTux schreibt, nach dem wegwerfen des Containers "weg". Deshalb sollte man auch einen Container eher "klein" halten. Für Alexa gibt es z.B. eigene Container. Wie ich schon schrieb: Container sind keine VMs.

[CoolTux]

Da fällt mir noch ein, wie Wernieman schrieb, kann man beim fhem Container beim erstellen des Containers ein init oder preinstall Script ausführen lassen soweit ich weiß.
Aber speziell für Alexa auf jeden Fall das Alexa Container Image verwenden.

Prinzip sollte sein, ein Container bildet immer eine einzige Anwendung ab. Im besten Fall sogar nur ein binary. Aber das mit dem nur ein binary ist eher selten 😁

[Sidey]

Hallo,


Das preinstall script im FHEM Image ist deprecated.
Die Vorgehensweise ist in der Image Dokumentation beschrieben.
Es läuft darauf hinaus, dass ein neues Image erzeugt wird.


Was mich interessiert:
Was fehlt denn im FHEM Image um FHEM zu betreiben?

Grüße Sidey

[CoolTux]

Um FHEM an sich zu betreiben fehlt nichts. FHEM ist mit dem aktuellen Image zu 99 Prozent der Haushalte zu betreiben. Ich denke man sollte eine Wikiseite einrichten in der das Prinzip und die Funktionsweise des Images erläutert wird und die Verfügbaren SiteCare Images erwähnt werden. Also sowas wie fhem-alexa und so.

[Marko1976]

Der fhem Container ist so aufgebaut das eigentlich das ganze fhem Verzeichnis, also das root von fhem auf einem Volume liegen sollte. So ist die Idee und am Ende bleibt halt im Container das System.

Ich denke wir reden an einander vorbei. Das System ist sicher komplett, aber ich musste im Laufe der Jahre etliche Erweiterungen installieren, damit z. B. nodeJS funktioniert. Und das ist auch von den Fhem-Betreibern so vorgesehen, da jeder andere Anwendungsideen hat und Fhem ja frei geändert/angepasst werden kann. Wenn man in den Container von vornherein alles reinpacken würde, würde er unnütz aufgeblät und 50% der Sachen nicht genutzt. Und ich kenne niemanden der jedesmal wenn er etwas nachinstalliert hat ein neues Volume/Container daraus erstellt hat. abgesehen davon, dass das ja auch nicht sinnvoll wäre, denn die Distribution ändert sich ja auch und darauf habe ich als Anwender gar keinen Einfluss.
Ich muss also wenn ich einen Distributionswechsel z.b. von Buster auf Bullseye mache auch die Sachen erneut nachinstallieren.

Wenn Dein alter Container gelöscht ist dann ist alles weg was direkt im Container war, also nicht in ein Volume gespeichert wurde.

Gut, dann muss ich dait leben und versuche die Sachen durch Ausschluss wieder zu finden. Aktuell weiß ich nur vom nodeJS.

Genau das meinte ich mit persistente Daten. Also entweder per "mount" in ein Docker-Volumen oder in ein Verzeichnis. Bei Single Docker-Systemen würde ich für Anfänger die Speicherung in Verzeichnisse Empfehlen. Aber DAS ist nur meine Meinung.

Warum schriebst du dann nicht auch der einfach heit halber Container? Daten kann alles mögliche sein.

Ein Container (und auch der FHEM Container ist so) soll eigentlich fertig sein, eventuell wird beim ersten Starten AUTOMATISCH Sachen nachinstalliert. Jede Manuelle Nachinstallation ist, wie CoolTux schreibt, nach dem wegwerfen des Containers "weg". Deshalb sollte man auch einen Container eher "klein" halten. Für Alexa gibt es z.B. eigene Container. Wie ich schon schrieb: Container sind keine VMs.

Wie oben geschrieben ist dem eben nicht so. Ich weiß ja nicht wer von euch auf einem QNAP einen Fhem-Container betreibt, aber da ist es eben definitiv nicht so. Bei anderen Containern mag das zutreffend sein und auch sinnvoll, doch Fhem ist wie bereits geschrieben zu unterschiedlich in der Anwendung. Und ja, es gibt sicherlich auch fertige Container mit Alexa-Unterstützung, doch das war ja nicht das einzige sondern nur EIN Beispiel.

Da fällt mir noch ein, wie Wernieman schrieb, kann man beim fhem Container beim erstellen des Containers ein init oder preinstall Script ausführen lassen soweit ich weiß.
Aber speziell für Alexa auf jeden Fall das Alexa Container Image verwenden.

Eben nicht, denn das läuft noch immer auf der veralteten Bsuter Distribution.

Prinzip sollte sein, ein Container bildet immer eine einzige Anwendung ab. Im besten Fall sogar nur ein binary. Aber das mit dem nur ein binary ist eher selten 😁

Ich denke nach wie vor wir reden aneinander vorbei. Ich meine nicht verschiedene Anwendungen innerhalb eines Containers, sondern NUR Funktionen die nicht standardmäßig in der Containerumgebung aktiviert sind. Da gabe es mindestens 5 verschiedene die ich im Laufe der Zeit mit apt sudo über die Konsole aktiveren musste um spezielle Fähigkeiten in Fhem auf dem Containe rnutzen zu können. Wenn ich mich richtig erinner war da z. B. auch für TUYA etwas nachzuinstallieren, aber da bin ich mir nicht mehr sicher da der Container jahrelang lief ohne das er verändert wurde.

Was fehlt denn im FHEM Image um FHEM zu betreiben?

NICHTS! Das ist doch meine Rede. Aber ich musste Funktionen "freischalten/aktivieren" um besondere Dinge innerhalb von Fhem nutzen zu können. Fhem selbst läuft mit der Standardinstallation. Es geht hier um Erweiterungen nicht um Fhem selbst. Das dumme ist halt, dass ich mich nicht mehr erinnere was es alles war. Eventuell ist ja in der neusten Container-Version einiges mehr drin "freigeschaltet" als zu Buster-Zeiten, das weiß ich ja nicht.

Da ich jetzt eh jedes Device einzeln auf den neuen Container übertragen muss und dabei gleichzeitig mal aufräumen werde, wird sich ja zeigen wenn etwas nicht funktionieren sollte.

[Sidey]

Die Images für FHEM und Alexa-FHEM werden derzeit auf Basis von Debian Bookworm erstellt.

Die Erweiterungen gehören in eigene Container und nicht in den FHEM Container. Siehe Alexa-FHEM.

Die ganzen Beschreibungen etwas mit apt zu installieren, die vielfach in der commandref zu finden sind, beziehen sich nicht auf die Container Images sondern meist auf Ubuntu Installationen abseits von Containern.
Das steht da leider nicht.

Die Idee mit der WIKI Seite finde ich prinzipiell gut. Etliches steht aber auch bereits in der README.md der container Repositorys.
Unter anderem auch, dass man in den container selbst nichts nachinstallieren kann und dazu ein neues Image bauen muss.

Es gibt ja auch Image Ersteller, die entfernen die Paketmanager um diesem Verhalten des Nachinstallieren entgegen zu wirken.

Die manuelke Nachinstallation hat auch den Nebeneffekt, dass man quasi nie das Image aktualisieren kann, weil ja dann alle Anpassungen wieder weg sind. Da lauern dann bestimmt etliche Sicherheitslücken.
Gut, da ist jeder selbst für verantwortlich.

Grüße Sidey