network_mode: host bringt auch die Hardware des Servers mit — und dann laufen die Logs im Sekundentakt voll

Was ich gebaut habe: Home Assistant als Container auf dem vorhandenen Server — nach dem Muster, in dem bei mir alle anderen Dienste laufen. Die Entscheidung dafür steht in Container auf dem vorhandenen Server.

Zwei Dinge habe ich bewusst anders gemacht, als es die schnellste Anleitung vorschlägt:

Die Version festgenagelt statt „nimm die aktuelle Stable". Home Assistant veröffentlicht häufig, und ein unbemerkter Versionssprung beim nächsten Neustart wäre bei einer Haussteuerung unangenehm. Ein Update soll etwas sein, das ich mache — nicht etwas, das passiert.

network_mode: host gesetzt, weil die automatische Geräteerkennung sonst nicht funktioniert: Sie arbeitet mit Rundrufen im lokalen Netz, und die kommen in einem eigenen Container-Netz nicht an. Das ist eine bewusste Abweichung von meinem Prinzip „keine unnötig offenen Ports" und steht als Kommentar direkt in der Compose-Datei. Ein anderer Dienst bei mir macht das aus demselben Grund schon — ich musste also keine neue Konvention erfinden.

Und genau daran hing dann der Ärger.

Das Problem: Direkt nach dem ersten Start lief das Log im Sekundentakt mit Fehlern voll — der Container konnte einen Bluetooth-Adapter nicht ansteuern und meldete fehlende Berechtigungen.

Die Ursache war das, was ich selbst konfiguriert hatte. network_mode: host bringt nicht nur Netzzugriff mit, sondern auch die Hardware-Erkennung des Hosts. Home Assistant sah also den Bluetooth-Adapter des Servers und legte beim ersten Start automatisch einen Eintrag dafür an. Bedienen konnte er ihn nicht: Der dafür nötige Systemdienst ist nicht in den Container durchgereicht, und die entsprechenden Rechte fehlen ebenfalls — beides absichtlich.

Die Lösung war, ihm die Rechte nicht zu geben. Der naheliegende Weg wäre gewesen, den Systemdienst durchzureichen und die fehlenden Berechtigungen zu ergänzen. Dann hätte der Container Rechte am Netzwerk-Stack des Hosts — für eine Funktion, die ich gar nicht benutze. Stattdessen habe ich den Bluetooth-Eintrag auf „deaktiviert" gesetzt.

Kleiner Stolperstein dabei: Löschen allein half nicht. Die automatische Erkennung legt den Eintrag sofort neu an. Er muss ausdrücklich deaktiviert werden, nicht entfernt.

Seitdem: null Fehlerzeilen im Log. Bluetooth bleibt aus und kann später bewusst aktiviert werden, wenn ich es wirklich brauche — dann mit den nötigen Rechten und dem Wissen, warum sie da sind.

Was ich mitnehme: network_mode: host ist bequemer, als vielen klar ist, und weitreichender auch. Der Container sieht damit die Hardware des Servers. Was er davon nicht braucht, wird gezielt abgeschaltet — nicht mit zusätzlichen Rechten bedienbar gemacht.

Und ein Befund, der mich beim Sondieren des Netzes überrascht hat: Ich hatte mit einem smarten Zwischenstecker gerechnet. Es waren fünf — über Monate angeschafft, teilweise mit Firmware aus verschiedenen Jahren, und keiner bot ab Werk eine Authentifizierung an. Das ist bei Geräten dieser Klasse üblich und kein Einbruch, aber es war mir in dieser Deutlichkeit nicht bewusst. Wer Smart-Home-Geräte einbindet, sollte einmal nachsehen, wie viele es tatsächlich sind, welche Firmware sie fahren und ob sie eine Authentifizierung anbieten — und ihnen bei der Gelegenheit den Weg ins Internet sperren, falls sie ihn nicht brauchen.

Update (2026-08-27): Das damals noch offene Einrichten im Browser hat sich erledigt — einen Tag später habe ich Home Assistant wieder abgebaut; die Gründe stehen dort. Die Erkenntnisse aus diesem Eintrag bleiben davon unberührt: network_mode: host bringt die Host-Hardware mit, und abschalten schlägt berechtigen.