Behörighetsdrift uppstår när Home Assistant-data fortfarande finns kvar, men processen som nu monterar den ser ett annat ägarskap, andra UID/GID-mappningar, åtkomstlägen eller säkerhetskontext än processen som skapade den. Felet uppstår ofta efter en värdmigrering, återställning, ändring av Docker-läge, NAS-kopiering eller en manuell chown/chmod-åtgärd.
Förhindra det genom att dokumentera den förväntade monterings- och ägandemodellen innan en ändring, bevara metadata vid kopiering och testa både läs- och skrivåtkomst efter återskapandet. Normalisera inte varje fel med chmod -R 777; det döljer avvikelsen och försvagar återställningsmodellen.
Dokumentera lagringsgränsen innan du ändrar behörigheter
Börja med att identifiera om /config är en Docker-hanterad volym, en Linux-bindmontering, en nätverksmontering eller en sökväg inuti en virtuell maskin. Rätt ägarstrategi beror på vilket lager som faktiskt äger filerna.
Home Assistants aktuella installationsanvisningar för Container gör detta lagringsavtal konkret: den valda mappen på värden monteras till /config med läs- och skrivåtkomst. Notera den exakta källsökvägen, monteringsmålet och åtkomstläget i stället för att enbart förlita dig på ett mappnamn.
Notera också om Home Assistant körs via standard-Docker, rootless Docker, ett ommappat användarnamnområde eller en NAS-behållarhanterare. De numeriska identiteterna som visas inuti och utanför containern behöver inte vara desamma.
UID- och GID-mappning kan ändras utan att filerna flyttas
En mapp kan ligga kvar på samma sökväg på värden medan den effektiva användarmappningen ändras under den. Detta är vanligt vid övergång från rootful till rootless Docker, när användarnamnområdesmappning aktiveras eller när data återställs till en värd med andra lokala konton.
Dockers aktuella dokumentation om UID/GID-mappning visar att rootless- och användarnamnområdeslägen översätter containeridentiteter till andra ID:n på värden. En fil som verkar ha rätt ägare på en värd kan därför bli skrivskyddad efter att distributionsmodellen ändras.
Jämför numeriskt ägarskap med ls -ln eller motsvarande verktyg i stället för att enbart förlita dig på kontonamn, eftersom dessa kan motsvara andra nummer på den nya värden.
Bevara metadata när du kopierar Home Assistant-data
Ett migreringsverktyg eller en grafisk filkopiering kan bevara filinnehåll men inte ägarskap, lägesbitar, ACL:er, utökade attribut eller säkerhetsetiketter. Då kan YAML-filer vara läsbara medan databaser, dold lagring, certifikat eller kataloger som krävs för skrivningar senare misslyckas.
Använd en kopieringsmetod som bevarar den metadata som faktiskt används av din plattform. Jämför representativa filer och kataloger från källan och målet efter överföringen, innan du startar Home Assistant.
ZimaSpaces guide om att behandla konton och behörigheter som en återanvändbar hushållspolicy är relevant även här: ägarskap bör vara genomtänkt infrastruktur, inte en serie tillfälliga engångsfixar.
Behåll monteringen skrivbar endast där Home Assistant behöver skriva
Home Assistant måste kunna uppdatera sin beständiga konfiguration och databas. En bindmontering som av misstag återskapas som skrivskyddad kan tillåta starter och läsningar, men senare skrivningar, säkerhetskopior, databaskommandon eller konfigurationsändringar kan misslyckas.
Bindmonterade sökvägar på värden kan exponeras med läs- och skrivåtkomst eller som skrivskyddade. Dockers guide om fildelning visar att det effektiva monteringsläget avgör om en container kan ändra värdkatalogen. Kontrollera den aktiva monteringen i stället för att anta att Compose-filen tillämpades som avsett.
Gör samtidigt inte orelaterade kataloger på värden skrivbara bara för att Home Assistant behöver åtkomst till en enda konfigurationssökväg. Håll behörighetsgränsen snäv.
Använd ett behörighetstest efter varje återställning eller återskapande
En lyckad start bevisar bara en del av filsystemskontraktet. Home Assistant kan läsa befintliga filer men senare misslyckas när den behöver skriva till databasen, skapa en säkerhetskopia, uppdatera ett register eller spara en instrumentpanel.
- Bekräfta att den förväntade konfigurationen och integrationerna läses in.
- Gör en ofarlig ändring som hanteras via gränssnittet och kontrollera att den finns kvar efter omstart.
- Bekräfta att Recorder skriver en ny statusändring.
- Skapa en liten säkerhetskopia om installationstypen stöder det.
- Granska loggarna efter fel som rör nekad behörighet, skrivskyddat filsystem eller databasskrivning.
Om testet misslyckas ska du korrigera den specifika ägare, grupp, ACL, namnområdesmappning eller monteringsläge som styr sökvägen. Behörighetsdrift är åtgärdad när den dokumenterade distributionen kan återskapa korrekt åtkomst utan manuella nödfallskommandon.
Support och tips
Mer att läsa

Tecken på att en Home Assistant-databas behöver underhåll eller bytas ut
En stor Home Assistant-databas behöver vanligtvis underhåll av lagringstid eller rensning; återkommande korruption eller integritetsfel är starkare signaler på att den bör bytas ut.

Hur många samtidiga användare klarar Home Assistant innan det börjar gå långsammare?
Home Assistant har ingen fast praktisk gräns för antalet användare: testa aktiva klienter med riktiga instrumentpaneler och entitetsuppdateringar och sluta innan återkommande fördröjningar uppstår.

Kan Home Assistant använda en extern databas utan att uppgraderingar slutar fungera?
En extern Recorder-databas kan överleva uppgraderingar, men medför eget ansvar för tillgänglighet, schemamigrering, säkerhetskopiering, återställning och versionshantering.

