Hoe voorkom je permissiedrift in Home Assistant-gegevensmappen

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Prevent Permission Drift in Home Assistant Data Folders

Permissiedrift ontstaat wanneer de Home Assistant-gegevens nog aanwezig zijn, maar het proces dat ze nu koppelt andere eigenaars, UID/GID-toewijzingen, toegangsmodi of beveiligingscontexten ziet dan het proces dat ze heeft aangemaakt. De fout doet zich vaak voor na een hostmigratie, herstelactie, wijziging van de Docker-modus, NAS-kopie of handmatige bewerking met chown/chmod.

Voorkom dit door vóór een wijziging het verwachte koppelings- en eigenaarschapsmodel te documenteren, metadata tijdens het kopiëren te behouden en na het opnieuw aanmaken zowel lees- als schrijftoegang te testen. Los niet elke fout op met chmod -R 777; daarmee verberg je de mismatch en verzwak je het herstelmodel.

Documenteer de opslaggrens voordat je machtigingen wijzigt

Begin met vaststellen of /config een door Docker beheerd volume, een Linux-bindkoppeling, een netwerkkoppeling of een pad binnen een VM is. De juiste eigenaarschapsstrategie hangt af van de laag die daadwerkelijk eigenaar is van de bestanden.

De huidige installatie-instructies voor Home Assistant Container maken dit opslagcontract concreet: de geselecteerde map op de host wordt met lees- en schrijftoegang gekoppeld aan /config. Leg dat exacte bronpad, koppelpunt en toegangsmodus vast in plaats van alleen op een mapnaam te vertrouwen.

Noteer ook of Home Assistant draait via standaard Docker, rootless Docker, een opnieuw toegewezen gebruikersnaamruimte of een NAS-containerbeheerder. De numerieke identiteiten binnen en buiten de container zijn mogelijk niet hetzelfde.

UID- en GID-toewijzingen kunnen veranderen zonder dat de bestanden worden verplaatst

Een map kan op hetzelfde hostpad blijven staan terwijl de effectieve gebruikertoewijzing eronder verandert. Dit komt vaak voor bij de overstap van rootful naar rootless Docker, het inschakelen van toewijzing van gebruikersnaamruimten of het herstellen van gegevens op een host met andere lokale accounts.

De huidige documentatie van Docker over UID/GID-toewijzing laat zien dat rootless- en gebruikersnaamruimtemodi containeridentiteiten vertalen naar andere host-ID's. Een bestand dat op de ene host de juiste eigenaar lijkt te hebben, kan daardoor niet schrijfbaar worden nadat het implementatiemodel verandert.

Vergelijk numerieke eigenaars met ls -ln of gelijkwaardige hulpprogramma's in plaats van alleen op accountnamen te vertrouwen, omdat die op de nieuwe host aan andere nummers kunnen zijn gekoppeld.

Behoud metadata bij het kopiëren van de Home Assistant-gegevens

Een migratietool of grafische bestandskopie kan de bestandsinhoud behouden, maar niet de eigenaars, modusbits, ACL's, uitgebreide attributen of beveiligingslabels. Daardoor kunnen YAML-bestanden leesbaar blijven, terwijl databases, verborgen opslag, certificaten of mappen die nodig zijn voor schrijven later fouten veroorzaken.

Gebruik een kopieermethode die de metadata behoudt die je platform daadwerkelijk gebruikt. Vergelijk na de overdracht representatieve bestanden en mappen van de bron en de bestemming voordat je Home Assistant start.

De ZimaSpace-gids over het behandelen van accounts en machtigingen als herhaalbaar huishoudelijk beleid is hier van toepassing: eigenaarschap moet doelbewuste infrastructuur zijn, geen reeks eenmalige oplossingen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Houd de koppeling alleen daar lees-schrijvbaar waar Home Assistant moet kunnen schrijven

Home Assistant moet de permanente configuratie en database kunnen bijwerken. Een koppeling die per ongeluk opnieuw als alleen-lezen is aangemaakt, kan opstarten en lezen toestaan, terwijl latere schrijfbewerkingen, back-ups, databasecommits of configuratiewijzigingen mislukken.

Bindgekoppelde hostpaden kunnen lees-schrijvbaar of alleen-lezen beschikbaar worden gesteld. De bestandsdelingsgids van Docker laat zien dat de effectieve koppelmodus bepaalt of een container de hostmap kan wijzigen. Controleer de actieve koppeling in plaats van ervan uit te gaan dat het Compose-bestand correct is toegepast.

Maak omgekeerd geen niet-gerelateerde hostmappen schrijfbaar alleen omdat Home Assistant toegang tot één configuratiepad nodig heeft. Houd de machtigingsgrens beperkt.

Gebruik na elk herstel of opnieuw aanmaken een machtigingstest

Een succesvolle start bewijst slechts een deel van het bestandssysteemcontract. Home Assistant kan bestaande bestanden lezen, maar later mislukken wanneer het de database moet beschrijven, een back-up moet maken, een register moet bijwerken of een dashboard moet opslaan.

Controleer of de verwachte configuratie en integraties worden geladen.
Breng één onschadelijke, via de interface beheerde wijziging aan en controleer of deze na een herstart behouden blijft.
Controleer of Recorder een nieuwe statuswijziging opslaat.
Maak een kleine back-up als het installatietype dit ondersteunt.
Controleer de logboeken op fouten zoals geen toegang, alleen-lezen bestandssysteem of schrijffouten in de database.

Als de test mislukt, corrigeer dan de specifieke eigenaar, groep, ACL, naamruimtetoewijzing of koppelmodus die verantwoordelijk is voor het pad. Permissiedrift is opgelost wanneer de gedocumenteerde implementatie de juiste toegang opnieuw kan instellen zonder handmatige noodcommando's.