Waarom verliest Home Assistant de toegang tot persistente gegevens na het opnieuw aanmaken van de stack?

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 Lose Access to Persistent Data After Stack Recreation?

Het opnieuw maken van een Home Assistant Docker- of Compose-stack zou de configuratie niet moeten wissen wanneer dezelfde persistente /config-gegevens opnieuw worden gekoppeld. Wanneer de onboarding opnieuw verschijnt of integraties na het opnieuw maken lijken te ontbreken, moet de eerste aanname zijn dat de nieuwe container een andere opslagweergave ziet — niet dat Home Assistant de huishoudstatus heeft verwijderd.

Controleer de effectieve mount, het hostpad, het benoemde volume, verborgen bestanden en machtigingen voordat je een oudere back-up terugzet. Een verkeerde lege map kan er precies uitzien als configuratieverlies, terwijl de oorspronkelijke gegevens elders op de host nog intact zijn.

Controleer wat er daadwerkelijk op /config is gekoppeld

Inspecteer de actieve container en bevestig welke bron aan /config is gekoppeld. Vergelijk deze met het oude Compose-bestand of implementatieregister in plaats van te vertrouwen op een vertrouwd ogende mapnaam.

Docker-bindmounts vervangen de weergave van de container van de doelmap, en de huidige documentatie over bindmounts vermeldt dat het mounten van een hostmap over een niet-lege containerlocatie de bestanden die daar al stonden aan het zicht onttrekt. Door een lege of verkeerde bronmap ziet Home Assistant dus een lege /config.

Start de onboarding niet en begin geen nieuwe integraties aan te maken totdat de mount is geverifieerd. Nieuwe schrijfbewerkingen naar de verkeerde map maken later herstel alleen maar verwarrender.

Maak onderscheid tussen bindmounts en benoemde volumes

Een Compose-stack kan een expliciet hostpad of een door Docker beheerd benoemd volume gebruiken. Wanneer je een project opnieuw maakt met een andere projectnaam, volumenaam of pad, kan er een nieuwe lege persistente opslag worden aangemaakt terwijl het oude volume nog bestaat.

Een actuele Docker-volumegids legt uit dat benoemde volumes gegevens onafhankelijk van afzonderlijke containers opslaan en opnieuw kunnen worden gekoppeld nadat een container is vervangen. Een container verwijderen is daarom iets anders dan de persistente opslag verwijderen of vervangen.

Bekijk de oude en nieuwe volumes, inspecteer hun mountpunten via Docker en vergelijk aanmaaktijden en inhoud. Gebruik geen prune-opdrachten totdat je weet welk volume de gezaghebbende Home Assistant-status bevat.

Door verborgen bestanden kan een kopie compleet lijken terwijl dat niet zo is

Home Assistant slaat belangrijke, via de interface beheerde status op in verborgen paden zoals .storage. Een shellkopie met een glob zoals *, of een bestandsbeheerder die puntbestanden verbergt, kan YAML-bestanden verplaatsen terwijl essentiële register- en integratiestatus ongemerkt achterblijft.

Een migratiegeval van Docker naar Compose uit 2025 reproduceerde precies deze grens: bij een kopieerbewerking werd verborgen Home Assistant-status overgeslagen of verkeerd verwerkt, en de migratie werd pas stabiel nadat de volledige configuratiestructuur en metadata correct waren gekopieerd.

Vergelijk directorylijsten waarin puntbestanden zijn opgenomen en controleer eigenaarschap, tijdstempels en de aanwezigheid van verwachte verborgen mappen voordat je concludeert dat de gegevens zelf beschadigd zijn.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Controleer machtigingen voordat je de gegevens opnieuw kopieert

De juiste map kan nog steeds onbruikbaar lijken wanneer de opnieuw gemaakte container geen toestemming heeft om deze te lezen of te beschrijven. Dit komt vaak voor nadat de gegevens naar een nieuw bestandssysteem zijn verplaatst, de Docker-modus is gewijzigd, gegevens vanaf een andere host zijn teruggezet of UID/GID-toewijzingen zijn veranderd.

Een Docker Engine-probleemoplossingsgids die in 2026 is gecontroleerd, beperkt deze fouten tot het echte hostpad, de container-UID/GID, toegang tot bovenliggende mappen, de mountmodus en beveiligingsgrenzen. Een alleen-lezeninstelling of mismatch in eigenaarschap kan verhinderen dat Home Assistant de status bijwerkt, zelfs wanneer de bestanden zichtbaar zijn.

Los het specifieke probleem met eigenaarschap of de mount op in plaats van de volledige configuratiestructuur wereldwijd beschrijfbaar te maken.

Maak de stack pas opnieuw nadat het persistente pad is geverifieerd

Gebruik exact de bekende goede Compose-definitie, imagetag, netwerkmodus, apparaten en /config-bron. Start Home Assistant en controleer of de verwachte gebruikers, dashboards, integraties, automatiseringen en helpers terugkeren voordat je migraties of nieuwe configuratiewijzigingen toestaat.

De workflow voor herstel van één container van ZimaSpace past dezelfde regel toe: inspecteer effectieve mounts en verbind gezonde afhankelijkheden opnieuw voordat je niet-gerelateerde onderdelen van een stack terugzet of vervangt.

Als de gezaghebbende gegevens werkelijk ontbreken, ga dan over op herstel vanuit een back-up. Als ze wel aanwezig zijn, maar de nieuwe container ze niet kan zien of wijzigen, ligt het probleem bij de opslagkoppeling of machtigingsgrens, niet bij de Home Assistant-configuratie zelf.