So verhindern Sie Berechtigungsabweichungen in Home-Assistant-Datenordnern

Berechtigungsdrift tritt auf, wenn die Home-Assistant-Daten weiterhin vorhanden sind, der Prozess, der sie nun einbindet, jedoch andere Besitzverhältnisse, UID/GID-Zuordnungen, Zugriffsmodi oder Sicherheitskontexte vorfindet als der Prozess, der sie erstellt hat. Der Fehler tritt häufig nach einer Host-Migration, einer Wiederherstellung, einer Änderung des Docker-Modus, dem Kopieren auf ein NAS oder einer manuellen chown/chmod-Operation auf.

Verhindern Sie dies, indem Sie vor einer Änderung das erwartete Einbindungs- und Besitzmodell dokumentieren, Metadaten beim Kopieren erhalten und nach der Neuerstellung sowohl den Lese- als auch den Schreibzugriff testen. Setzen Sie nicht jeden Fehler mit chmod -R 777 zurück; dadurch wird die Abweichung lediglich verborgen und das Wiederherstellungsmodell geschwächt.

Dokumentieren Sie die Speichergrenze, bevor Sie Berechtigungen ändern

Ermitteln Sie zunächst, ob /config ein von Docker verwaltetes Volume, ein Linux-Bind-Mount, ein Netzwerk-Mount oder ein Pfad innerhalb einer VM ist. Die richtige Strategie für Besitzverhältnisse hängt davon ab, welche Ebene die Dateien tatsächlich verwaltet.

Die aktuelle Installationsanleitung für Home Assistant Container konkretisiert diesen Speichervertrag: Der ausgewählte Host-Ordner wird mit Lese-/Schreibzugriff unter /config eingebunden. Notieren Sie den genauen Quellpfad, das Einbindungsziel und den Zugriffsmodus, statt sich allein auf einen Ordnernamen zu verlassen.

Dokumentieren Sie außerdem, ob Home Assistant über standardmäßiges Docker, Rootless Docker, einen neu zugeordneten Benutzer-Namespace oder einen NAS-Container-Manager ausgeführt wird. Die numerischen Identitäten innerhalb und außerhalb des Containers müssen nicht identisch sein.

UID- und GID-Zuordnungen können sich ändern, ohne dass die Dateien verschoben werden

Ein Ordner kann am selben Host-Pfad bleiben, während sich die effektive Benutzerzuordnung darunter ändert. Das kommt häufig vor, wenn von Root-Docker zu Rootless Docker gewechselt, die Zuordnung von Benutzer-Namespaces aktiviert oder Daten auf einem Host mit anderen lokalen Konten wiederhergestellt werden.

Die aktuelle Dokumentation von Docker zur UID/GID-Zuordnung zeigt, dass Rootless- und Benutzer-Namespace-Modi Containeridentitäten in andere Host-IDs übersetzen. Eine Datei, die auf einem Host scheinbar korrekt zugeordnet ist, kann daher nach einer Änderung des Bereitstellungsmodells nicht mehr beschreibbar sein.

Vergleichen Sie die numerischen Besitzverhältnisse mit ls -ln oder entsprechenden Werkzeugen, statt sich ausschließlich auf Kontonamen zu verlassen, die auf dem neuen Host anderen Nummern zugeordnet sein können.

Erhalten Sie die Metadaten beim Kopieren der Home-Assistant-Daten

Ein Migrationstool oder das Kopieren von Dateien über eine grafische Oberfläche kann zwar die Dateiinhalte, nicht aber Besitzverhältnisse, Modus-Bits, ACLs, erweiterten Attribute oder Sicherheitskennzeichnungen erhalten. Dadurch können YAML-Dateien lesbar bleiben, während Datenbanken, verborgener Speicher, Zertifikate oder für Schreibvorgänge benötigte Verzeichnisse später Probleme verursachen.

Verwenden Sie eine Kopiermethode, die die von Ihrer Plattform tatsächlich verwendeten Metadaten erhält. Vergleichen Sie nach der Übertragung repräsentative Dateien und Verzeichnisse aus Quelle und Ziel, bevor Sie Home Assistant starten.

Die ZimaSpace-Anleitung zum Behandeln von Konten und Berechtigungen als wiederholbare Haushaltspolitik ist auch hier relevant: Besitzverhältnisse sollten eine bewusst geplante Infrastruktur sein, keine Folge einzelner Notfallkorrekturen.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Halten Sie den Mount nur dort mit Lese-/Schreibzugriff bereit, wo Home Assistant schreiben muss

Home Assistant muss seine dauerhafte Konfiguration und Datenbank aktualisieren können. Ein versehentlich als schreibgeschützt neu erstellter Mount kann den Start und das Lesen ermöglichen, während spätere Schreibvorgänge, Sicherungen, Datenbank-Commits oder Konfigurationsänderungen fehlschlagen.

Über Bind-Mounts eingebundene Host-Pfade können mit Lese-/Schreibzugriff oder schreibgeschützt bereitgestellt werden. Der Leitfaden von Docker zum Dateiaustausch zeigt, dass der effektive Einbindungsmodus bestimmt, ob ein Container das Host-Verzeichnis ändern kann. Prüfen Sie den aktiven Mount, statt anzunehmen, dass die Compose-Datei wie beabsichtigt angewendet wurde.

Machen Sie umgekehrt keine unabhängigen Host-Verzeichnisse beschreibbar, nur weil Home Assistant Zugriff auf einen einzelnen Konfigurationspfad benötigt. Halten Sie die Berechtigungsgrenze eng.

Führen Sie nach jeder Wiederherstellung oder Neuerstellung einen Berechtigungstest durch

Ein erfolgreicher Start bestätigt nur einen Teil des Dateisystemvertrags. Home Assistant kann vorhandene Dateien lesen, später aber scheitern, wenn es die Datenbank schreiben, eine Sicherung erstellen, eine Registry aktualisieren oder ein Dashboard speichern muss.

• Bestätigen Sie, dass die erwartete Konfiguration und die Integrationen geladen werden.
• Nehmen Sie eine harmlose, über die Benutzeroberfläche verwaltete Änderung vor und prüfen Sie, ob sie nach einem Neustart erhalten bleibt.
• Bestätigen Sie, dass Recorder eine neue Zustandsänderung schreibt.
• Erstellen Sie eine kleine Sicherung, sofern der Installationstyp dies unterstützt.
• Prüfen Sie die Protokolle auf Fehler wie „Permission denied“, ein schreibgeschütztes Dateisystem oder Datenbankschreibfehler.

Wenn der Test fehlschlägt, korrigieren Sie den konkreten Besitzer, die Gruppe, ACL, Namespace-Zuordnung oder den Mount-Modus, der für den Pfad zuständig ist. Berechtigungsdrift ist behoben, wenn die dokumentierte Bereitstellung den korrekten Zugriff ohne manuelle Notfallbefehle wiederherstellen kann.