Varför återskapar Home Assistant saknade filer med fel ägare?
Home Assistant väljer inte automatiskt ett användarvänligt värd-användarnamn när det återskapar en fil. Den nya filen ärver normalt det numeriska UID:t, GID:t, umask-värdet, ACL:en och filsystemets regler från processen som skapade den inuti containern.
Detta blir synligt på en bind-montering eftersom Linux registrerar numeriska identiteter, medan värden och container kan koppla olika namn till samma nummer. Innan du ändrar behörigheter ska du stoppa Home Assistant, notera de gamla och nya numeriska ägarna, identifiera runtime-processen och fastställa om filen skapades av Home Assistant, en entrypoint, ett säkerhetskopieringsverktyg eller värden.
Bekräfta vilken process som skapade filen
Jämför filens skapande- eller ändringstid med tiden för containerstart, återställning, uppdatering eller ett tilläggsjobb. Kontrollera sedan det numeriska UID:t och GID:t på värden samt identiteten för Home Assistant-processen inuti containern. Användarnamn kan skilja sig åt; nummer är den tillförlitliga jämförelsen.
Det underliggande containerproblemet är att bind-monterade filer skapas under den identitet som används av containerprocessen. En oberoende förklaring av skillnaden mellan filsystemets ägare på värden och i containern visar varför det inte räcker att enbart matcha namn för att lösa skillnader i numeriska UID:n och GID:n.
Om den nya ägaren matchar containerprocessen är den primära orsaken bekräftad. Om den matchar root eller något annat hjälpprogram ska du granska entrypointen, återställningsverktyget, det schemalagda jobbet eller skriptet på värdsidan innan du ändrar Home Assistants runtime-användare.
Kontrollera monteringen, ACL:en och filsystemets gräns
Bekräfta att sökvägen är den avsedda bind-monteringen och inte en namngiven volym eller en bildkatalog som döljs av monteringen. Kontrollera den överordnade katalogens ägare, läge, standard-ACL och om filsystemet är lokalt, NFS, SMB eller en annan nätverksbaserad sökväg.
En process kan bara skapa en fil enligt de behörigheter och den mappning som filsystemet presenterar. Identitetsmappning i NFS, root squashing, SMB-monteringsalternativ, standard-ACL:er och en begränsande umask kan ändra den synliga ägaren eller skrivåtkomsten även när containerns UID är korrekt.
Om en tillfällig fil som skapats som runtime-UID får den förväntade ägaren ska du fortsätta med att identifiera den programspecifika skaparen. Om den får fel ägare ska du först åtgärda monteringen eller filsystemets mappning; en ändring av Home Assistant-konfigurationen kan inte åsidosätta det lagret.
Åtgärda endast den bekräftade ägarskillnaden
Stoppa Home Assistant innan du ändrar ägarskapet för en aktiv databas-, register- eller konfigurationsfil. Skapa en säkerhetskopia eller ögonblicksbild och ändra sedan endast den berörda sökvägen till det verifierade service-UID:t och GID:t. Bevara körbara bitar, ACL:er och särskilda behörigheter i stället för att tillämpa ett brett läge som skrivåtkomst för alla.
Uppdatera distributionsdefinitionen så att samma runtime-identitet används efter återskapandet, eller dokumentera varför avbildningen måste köras med sin standardidentitet och anpassa värdsökvägen efter den. Undvik att köra chown på hela katalogträdet vid varje uppstart; det kan vara långsamt, dölja designfel och ändra filer som ägs av andra tjänster.
ZimaSpaces guide om att förhindra behörighetsdrift innehåller en bredare driftchecklista för monteringar, ägarskap, skrivtester och återställningsbeteende efter att den omedelbara ägarskillnaden har korrigerats.
Verifiera ägarskapet efter återskapande och en riktig skrivning
Starta Home Assistant och utlös exakt den åtgärd som återskapade filen. Bekräfta att den nya filen har avsedd numerisk ägare, att Home Assistant kan uppdatera den och att säkerhetskopieringsprocessen på värdsidan kan läsa den. En lyckad uppstart utan någon skrivning bevisar inte att problemet är löst.
Starta om en gång och återskapa containern från den sparade konfigurationen. Ägare, ACL och skrivbeteende måste förbli stabila efter båda händelserna. Kontrollera loggarna efter fel om nekad behörighet, skrivskyddad databas, misslyckad säkerhetskopiering eller fel vid konfiguration av integrationer.
Kontakta bildens underhållare eller lagringsadministratören om den skapande identiteten oväntat ändras mellan versioner, om ett nätverksfilsystem skriver om ägarskapet eller om en nödvändig tjänst inte kan dela sökvägen på ett säkert sätt. Bevara de numeriska ID:na, monteringsdefinitionen, filsystemstypen och en minimal reproduktion.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Home Assistant-databasanslutningar för samtidiga containrar
Finjustera en extern Recorder-databas utifrån uppmätta aktiva anslutningar och svarstider, inte genom att höja det maximala antalet anslutningar eller kopiera en annan värds anslutningspool.
Så förhindrar du duplicerade jobb eller importer i Home Assistant
Använd spårningsdata och unika åtgärdsnycklar för att göra automatiseringar och importer säkra att försöka igen utan att skapa dubbla åtgärder eller poster.
Så reparerar du Home Assistant efter att databasvolymen blivit full
Återställ efter en full Recorder-volym utan att först radera bevismaterial, minska sedan tillväxten och bevisa att historik och automatiseringar överlever en omstart.
