Waarom maakt Home Assistant ontbrekende bestanden opnieuw aan met de verkeerde eigenaar?

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.

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

Home Assistant kiest geen gebruiksvriendelijke gebruikersnaam voor de host wanneer het een bestand opnieuw aanmaakt. Het nieuwe bestand neemt normaal gesproken de numerieke UID, GID, umask, ACL en bestandssysteemregels over van het proces dat het binnen de container heeft aangemaakt.

Dit wordt zichtbaar bij een bind-mount, omdat Linux numerieke identiteiten registreert, terwijl de host en de container verschillende namen aan hetzelfde nummer kunnen koppelen. Stop Home Assistant voordat je machtigingen wijzigt, noteer de oude en nieuwe numerieke eigenaren, identificeer het runtimeproces en bepaal of het bestand is aangemaakt door Home Assistant, een entrypoint, een back-uptool of de host.

Bevestig welk proces het bestand heeft aangemaakt

Vergelijk de aanmaak- of wijzigingstijd van het bestand met het starten van de container en met een herstel-, update- of add-ontak. Controleer vervolgens de numerieke UID en GID op de host en de identiteit van het Home Assistant-proces binnen de container. Gebruikersnamen kunnen verschillen; nummers zijn de betrouwbare vergelijking.

Het onderliggende containerprobleem is dat bestanden op een bind-mount worden aangemaakt onder de identiteit die door het containerproces wordt gebruikt. Een onafhankelijke uitleg van de niet-overeenkomen van de eigenaar van het hostbestandssysteem laat zien waarom alleen overeenkomende namen verschillen in numerieke UID en GID niet oplossen.

Als de nieuwe eigenaar overeenkomt met het containerproces, is de primaire oorzaak bevestigd. Komt deze overeen met root of een andere helper, controleer dan het entrypoint, de hersteltool, geplande taak of het script aan de hostzijde voordat je de runtimegebruiker van Home Assistant wijzigt.

Controleer de mount, ACL en bestandssysteemgrens

Bevestig dat het pad de bedoelde bind-mount is en geen benoemd volume of een afbeeldingsmap die door de mount wordt verborgen. Controleer de eigenaar, modus en standaard-ACL van de bovenliggende map en ga na of het bestandssysteem lokaal is of gebruikmaakt van NFS, SMB of een andere netwerkverbinding.

Een proces kan alleen een bestand aanmaken volgens de machtigingen en mapping die het bestandssysteem aanbiedt. Identiteitsmapping voor NFS, root-squashing, SMB-mountopties, standaard-ACL's en een beperkende umask kunnen de zichtbare eigenaar of schrijftoegang wijzigen, zelfs wanneer de container-UID correct is.

Als een tijdelijk bestand dat als de runtime-UID is aangemaakt de verwachte eigenaar krijgt, ga dan verder met het toepassingsspecifieke proces dat het bestand aanmaakt. Krijgt het de verkeerde eigenaar, herstel dan eerst de mount- of bestandssysteemmapping; het wijzigen van de Home Assistant-configuratie omzeilt die laag niet.

Herstel alleen de bevestigde eigenaarsmismatch

Stop Home Assistant voordat je het eigendom van actieve database-, register- of configuratiebestanden wijzigt. Maak een back-up of momentopname en wijzig vervolgens alleen het betreffende pad naar de geverifieerde service-UID en -GID. Behoud uitvoerbare bits, ACL's en speciale machtigingen in plaats van een brede modus zoals schrijfrechten voor iedereen toe te passen.

Werk de implementatiedefinitie bij zodat na het opnieuw aanmaken dezelfde runtime-identiteit wordt gebruikt, of documenteer waarom de image onder de standaardidentiteit moet draaien en laat het hostpad daarmee overeenkomen. Vermijd een chown van de volledige mappenstructuur bij elke start; dit kan traag zijn, ontwerpfouten verbergen en bestanden wijzigen die eigendom zijn van andere services.

De ZimaSpace-gids over het voorkomen van permissiedrift bevat de bredere controlelijst voor mounts, eigendom, schrijftests en herstelgedrag nadat de directe eigenaarsmismatch is gecorrigeerd.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Controleer het eigendom na het opnieuw aanmaken en een echte schrijfactie

Start Home Assistant en voer precies de bewerking uit die het bestand opnieuw heeft aangemaakt. Controleer of het nieuwe bestand de bedoelde numerieke eigenaar heeft, Home Assistant het kan bijwerken en het back-upproces aan de hostzijde het kan lezen. Een geslaagde start zonder schrijfactie bewijst niet dat de oplossing werkt.

Start de container eenmaal opnieuw en maak deze opnieuw aan vanuit de opgeslagen configuratie. De eigenaar, ACL en het schrijfgedrag moeten na beide gebeurtenissen stabiel blijven. Controleer de logs op meldingen over geweigerde machtigingen, een alleen-lezen database, een mislukte back-up of fouten bij het instellen van integraties.

Schakel de imagebeheerder of opslagbeheerder in als de aanmakende identiteit onverwacht verandert tussen versies, een netwerkbestandssysteem het eigendom herschrijft of een vereiste service het pad niet veilig kan delen. Bewaar de numerieke ID's, mountdefinitie, het bestandssysteemtype en een minimale reproductie.