Een permanente Tailscale-container zou na een herstart van ZimaOS of een bewerking van de applicatie dezelfde machine moeten blijven in de Tailscale-beheerdersconsole. In de brondiscussie uit september 2025 gebeurde dat niet: bij elke herstart of herimplementatie werd een nieuwe Tailscale-node aangemaakt, hoewel het Compose-bestand al gekoppeld was aan /var/lib/tailscale naar persistente ZimaOS AppData.
Het uiteindelijke resultaat uit de bron is belangrijk omdat het de oorzaak nader bepaalt. De oorspronkelijke poster zei dat de persistente opslag al correct was; het verwijderen van de voortdurend meegeleverde authenticatiesleutel was de enige wijziging die nodig was. Daarna bleef de identiteit van de Tailscale-node behouden.
Tailscale heeft persistente machinestatus nodig
Tailscale slaat de node-identiteit, sleutels en verbindingsstatus op in de statusmap. In Docker wordt het pad doorgaans geconfigureerd met:
TS_STATE_DIR=/var/lib/tailscaleAls die map alleen binnen het wegwerpbare bestandssysteem van de container bestaat, maakt het opnieuw aanmaken van de container een nieuwe Tailscale-identiteit.
De bron koppelde de statusmap al
Het oorspronkelijke Compose-bestand bevatte:
/DATA/AppData/tailscale:/var/lib/tailscalesamen met TS_STATE_DIR=/var/lib/tailscale, hostnetwerken, NET_ADMIN, NET_RAW, en toegang tot /dev/net/tun. Op papier zou dat de status moeten behouden.
Een authenticatiesleutel is bedoeld voor registratie, niet noodzakelijk voor elke herstart
Het Compose-bestand leverde ook TS_AUTHKEY bij elke containerstart. Een beantwoorder uit de community legde uit dat opnieuw authenticeren een nieuwe machine kan aanmaken wanneer de bestaande nodestatus niet wordt hergebruikt zoals verwacht.
De beantwoorder stelde voor om bij de eerste start een herbruikbare, niet-efemere authenticatiesleutel te gebruiken, te wachten tot de node in de beheerdersconsole verscheen, vervolgens de regel met de authenticatiesleutel te verwijderen en opnieuw te implementeren, zodat de opgeslagen machinestatus als identiteitsbron wordt gebruikt.
De oorspronkelijke poster bevestigde dat het verwijderen van de authenticatiesleutel het probleem oploste
Het uiteindelijke antwoord uit de bron vermeldt dat de andere onderdelen voor persistentie al aanwezig waren en dat alleen de omgevingsvariabele voor de authenticatiesleutel moest worden verwijderd. Daarna bleef de machinenaam behouden na herstarts.
Die bevestiging is sterker dan een algemene aanname over machtigingen. Voor deze specifieke installatie was herhaalde authenticatie de praktische oorzaak.
Huidige Tailscale biedt TS_AUTH_ONCE
Moderne Tailscale Docker-implementaties kunnen TS_AUTH_ONCE=true. Wanneer er al persistente status bestaat, zorgt dit ervoor dat de container niet bij elke start opnieuw moet inloggen.
Bekijk de huidige Tailscale-Dockerstatus- en authenticatieparameters voordat je een Compose-bestand uit 2025 ongewijzigd opnieuw gebruikt.
Gebruik een speciale hostmap voor de status
Een speciale hostdirectory, zoals een Tailscale AppData/statusmap, maakt het eenvoudiger om te controleren of de machinesleutels een herimplementatie overleven. De beantwoorder uit de bron adviseerde ook ervoor te zorgen dat de map schrijfbaar is voor het proces dat de Tailscale-status opslaat.
Machtigingen zijn belangrijk, omdat een volume correct gekoppeld kan zijn terwijl het proces de bestanden nog steeds niet kan bijwerken. In die situatie kan Tailscale zich gedragen alsof de machine geen herbruikbare status heeft.
Vermijd tijdelijke authenticatiesleutels voor een permanente server
Tailscale ondersteunt kortstondige nodes die opzettelijk tijdelijk zijn. Dat is nuttig voor kortdurende CI-taken of wegwerpcontainers, maar het is het tegenovergestelde van wat een permanente ZimaOS-server nodig heeft.
Controleer bij het aanmaken van een referentie of deze past bij de beoogde levenscyclus. Een persistente homeserver moet normaal gesproken dezelfde identiteit behouden totdat je deze bewust intrekt of vervangt.
TS_HOSTNAME bepaalt de machine-identiteit niet
De broncontainer gebruikte TS_HOSTNAME=zimaos. Die instelling bepaalt de gebruiksvriendelijke naam die aan het tailnet wordt gepresenteerd, maar het behouden van dezelfde hostnaamtekenreeks behoudt niet de cryptografische machine-identiteit. Twee nieuw geauthenticeerde machines kunnen allebei vergelijkbare namen proberen te gebruiken en toch afzonderlijke nodes blijven.
Test zowel herstart als herimplementatie van de app
Het oorspronkelijke probleem trad op na zowel volledige herstarts van het besturingssysteem als bewerkingen van de ZimaOS-app. Een correcte oplossing moet daarom beide doorstaan:
- de Tailscale-container opnieuw starten;
- de app bewerken en opnieuw implementeren zonder het statusvolume te wijzigen;
- ZimaOS opnieuw opstarten;
- controleer in de Tailscale-beheerconsole of dezelfde machine online blijft.
Als er na slechts een van deze gebeurtenissen een duplicaat verschijnt, vergelijk dan wat er tijdens die specifieke levenscyclusbewerking met de statusdirectory gebeurt.
Veelgestelde vragen over persistente Tailscale-status
Waarom werd er na elke herstart een nieuwe Tailscale-machine aangemaakt?
In het geval uit de bron bestond het statusvolume al en was herhaald gebruik van de authenticatiesleutel het resterende praktische probleem.
Welk pad moet persistent blijven?
Het pad dat is geconfigureerd door TS_STATE_DIRvaak /var/lib/tailscale in de container.
Moet TS_AUTHKEY voor altijd in de omgeving blijven staan?
Niet per se. De gebruiker uit de bron verhielp dubbele nodes door deze na de registratie te verwijderen, en de huidige Tailscale biedt ook TS_AUTH_ONCE.
Behoudt TS_HOSTNAME de node-identiteit?
Nee. De opgeslagen Tailscale-machinestatus behoudt de identiteit.
