Warum erstellt Home Assistant fehlende Dateien mit dem falschen Besitzer neu?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Why Does Home Assistant Recreate Missing Files With the Wrong Owner? - Zima Store Online

Home Assistant wählt keinen benutzerfreundlichen Host-Benutzernamen, wenn es eine Datei neu erstellt. Die neue Datei übernimmt normalerweise die numerische UID, GID, Umask, ACL und Dateisystemregeln des Prozesses, der sie innerhalb des Containers erstellt hat.

Bei einem Bind-Mount wird dies sichtbar, weil Linux numerische Identitäten speichert, während Host und Container derselben Nummer unterschiedliche Namen zuordnen können. Bevor Sie Berechtigungen ändern, stoppen Sie Home Assistant, notieren Sie die alten und neuen numerischen Eigentümer, ermitteln Sie den Laufzeitprozess und stellen Sie fest, ob die Datei von Home Assistant, einem Entrypoint, einem Backup-Tool oder dem Host erstellt wurde.

Bestätigen, welcher Prozess die Datei erstellt hat

Vergleichen Sie die Erstellungs- oder Änderungszeit der Datei mit dem Start des Containers sowie mit einem Wiederherstellungs-, Aktualisierungs- oder Add-on-Vorgang. Prüfen Sie anschließend die numerische UID und GID auf dem Host sowie die Identität des Home-Assistant-Prozesses im Container. Benutzernamen können abweichen; Zahlen sind der zuverlässige Vergleich.

Das zugrunde liegende Containerproblem besteht darin, dass Bind-Mount-Dateien unter der Identität erstellt werden, die der Containerprozess verwendet. Eine unabhängige Erklärung des Eigentümerkonflikts zwischen Host-Dateisystem und Container zeigt, warum übereinstimmende Namen allein numerische UID- und GID-Unterschiede nicht lösen.

Wenn der neue Eigentümer mit dem Containerprozess übereinstimmt, ist die Hauptursache bestätigt. Wenn er mit root oder einem anderen Hilfsprozess übereinstimmt, prüfen Sie den Entrypoint, das Wiederherstellungstool, den geplanten Auftrag oder das hostseitige Skript, bevor Sie den Laufzeitbenutzer von Home Assistant ändern.

Mount, ACL und Dateisystemgrenze prüfen

Bestätigen Sie, dass der Pfad der vorgesehene Bind-Mount und kein benanntes Volume oder ein Image-Verzeichnis ist, das durch den Mount verborgen wird. Prüfen Sie den Eigentümer und Modus des übergeordneten Verzeichnisses, die Standard-ACL sowie, ob es sich um einen lokalen Pfad, NFS, SMB oder einen anderen netzwerkbasierten Speicher handelt.

Ein Prozess kann eine Datei nur entsprechend den Berechtigungen und Zuordnungen erstellen, die das Dateisystem bereitstellt. NFS-Identitätszuordnung, Root-Squashing, SMB-Mount-Optionen, Standard-ACLs und eine restriktive Umask können den scheinbaren Eigentümer oder den Schreibzugriff verändern, selbst wenn die Container-UID korrekt ist.

Wenn eine temporäre Datei, die als Laufzeit-UID erstellt wurde, den erwarteten Eigentümer erhält, fahren Sie mit der Ermittlung des anwendungsspezifischen Erstellers fort. Wenn sie den falschen Eigentümer erhält, korrigieren Sie zuerst die Mount- oder Dateisystemzuordnung; eine Änderung der Home-Assistant-Konfiguration wird diese Ebene nicht überschreiben.

Nur die bestätigte Eigentümerabweichung beheben

Stoppen Sie Home Assistant, bevor Sie den Eigentümer aktiver Datenbank-, Registry- oder Konfigurationsdateien ändern. Erstellen Sie ein Backup oder einen Snapshot und ändern Sie anschließend nur den betroffenen Pfad auf die bestätigte Service-UID und -GID. Bewahren Sie Ausführungsbits, ACLs und Sonderberechtigungen, anstatt pauschal einen Modus wie weltweiten Schreibzugriff zu vergeben.

Aktualisieren Sie die Deployment-Definition so, dass nach einer Neuerstellung dieselbe Laufzeitidentität verwendet wird, oder dokumentieren Sie, warum das Image unter seiner Standardidentität ausgeführt werden muss, und passen Sie den Host-Pfad daran an. Vermeiden Sie ein Chown des gesamten Verzeichnisbaums bei jedem Start; dies kann langsam sein, Designfehler verschleiern und Dateien verändern, die anderen Diensten gehören.

Der ZimaSpace-Leitfaden zur Vermeidung von Berechtigungsabweichungen enthält die umfassendere Betriebskontrollliste für Mounts, Eigentümer, Schreibtests und das Verhalten bei der Wiederherstellung, nachdem die unmittelbare Eigentümerabweichung korrigiert wurde.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Eigentümer nach Neuerstellung und einem echten Schreibvorgang überprüfen

Starten Sie Home Assistant und lösen Sie genau den Vorgang aus, der die Datei neu erstellt hat. Bestätigen Sie, dass die neue Datei den vorgesehenen numerischen Eigentümer besitzt, Home Assistant sie aktualisieren kann und der hostseitige Backup-Prozess sie lesen kann. Ein erfolgreicher Start ohne Schreibvorgang beweist nicht, dass das Problem behoben ist.

Starten Sie den Container einmal neu und erstellen Sie ihn aus der gespeicherten Konfiguration neu. Eigentümer, ACL und Schreibverhalten müssen nach beiden Ereignissen stabil bleiben. Prüfen Sie die Protokolle auf Meldungen zu verweigerten Berechtigungen, schreibgeschützten Datenbanken, fehlgeschlagenen Backups oder Fehlern bei der Einrichtung von Integrationen.

Wenden Sie sich an den Image-Maintainer oder den Speicheradministrator, wenn sich die erstellende Identität zwischen Versionen unerwartet ändert, ein Netzwerkdateisystem den Eigentümer neu zuordnet oder ein erforderlicher Dienst den Pfad nicht sicher gemeinsam nutzen kann. Bewahren Sie die numerischen IDs, die Mount-Definition, den Dateisystemtyp und eine minimale Reproduktion auf.