En permanent Tailscale-container bör förbli samma maskin i Tailscales administratörskonsol efter en omstart av ZimaOS eller en redigering av applikationen. I källtråden från september 2025 skedde inte detta: varje omstart eller omdistribution skapade ytterligare en Tailscale-nod trots att Compose-filen redan monterade /var/lib/tailscale till beständig ZimaOS AppData.
Det slutliga källresultatet är viktigt eftersom det begränsar orsaken. Trådstartaren sa att den beständiga lagringen redan var korrekt; att ta bort miljövariabeln för autentiseringsnyckeln som angavs kontinuerligt var den enda ändring som behövdes. Därefter bestod Tailscale-nodens identitet.
Tailscale behöver beständigt maskintillstånd
Tailscale lagrar nodidentitet, nycklar och anslutningsstatus i sin statuskatalog. I Docker konfigureras sökvägen vanligtvis med:
TS_STATE_DIR=/var/lib/tailscaleOm den katalogen endast finns i det tillfälliga containerfilsystemet skapar en återskapad container en ny Tailscale-identitet.
Källan hade redan monterat statuskatalogen
Den ursprungliga Compose-filen innehöll:
/DATA/AppData/tailscale:/var/lib/tailscaletillsammans med TS_STATE_DIR=/var/lib/tailscale, värdnätverk, NET_ADMIN, NET_RAW, samt åtkomst till /dev/net/tun. På pappret borde det bevara statusen.
En autentiseringsnyckel används för registrering, inte nödvändigtvis vid varje omstart
Compose-filen angav också TS_AUTHKEY vid varje containerstart. En person i communityn förklarade att ny autentisering kan skapa en ny maskin när den befintliga nodstatusen inte återanvänds som förväntat.
Svarande föreslog att man använder en återanvändbar autentiseringsnyckel som inte är ephemeral vid den första starten, väntar tills noden visas i administratörskonsolen och sedan tar bort raden med autentiseringsnyckeln och distribuerar om, så att det sparade maskintillståndet blir identitetskälla.
Trådstartaren bekräftade att det löste problemet att ta bort autentiseringsnyckeln
Det slutliga källsvaret säger att de övriga delarna för beständig lagring redan fanns på plats och att endast miljövariabeln för autentiseringsnyckeln behövde tas bort. Maskinnamnet bestod sedan efter omstarter.
Den bekräftelsen är starkare än en allmän gissning om behörigheter. För just den här installationen var upprepad autentisering den praktiska utlösande faktorn.
Aktuell Tailscale tillhandahåller TS_AUTH_ONCE
Moderna Tailscale-distributioner med Docker kan använda TS_AUTH_ONCE=true. När beständig status redan finns talar detta om för containern att inte tvinga fram en ny inloggning varje gång den startar.
Granska de aktuella Tailscale-parametrarna för Docker-tillstånd och autentisering innan du återanvänder en Compose-fil från 2025 oförändrad.
Använd en dedikerad värdmapp för tillstånd
En dedikerad värdkatalog, till exempel en Tailscale AppData-/tillståndskatalog, gör det enklare att verifiera att maskinnycklarna överlever en omdistribution. Källansvariga rekommenderade också att säkerställa att katalogen är skrivbar för den process som lagrar Tailscale-tillståndet.
Behörigheter spelar roll eftersom en volym kan vara korrekt monterad samtidigt som processen fortfarande inte kan uppdatera filerna. I så fall kan Tailscale bete sig som om maskinen saknar återanvändbart tillstånd.
Undvik efemära autentiseringsnycklar för en permanent server
Tailscale stöder efemära noder som avsiktligt är tillfälliga. Det är användbart för kortlivade CI-jobb eller engångscontainrar, men är motsatsen till vad en permanent ZimaOS-server behöver.
När du skapar en autentiseringsuppgift ska du kontrollera att den motsvarar den avsedda livscykeln. En beständig hemmaserver bör normalt behålla samma identitet tills du avsiktligt återkallar eller ersätter den.
TS_HOSTNAME definierar inte maskinidentiteten
Källcontainern använde TS_HOSTNAME=zimaos. Den inställningen styr det användarvänliga namnet som visas för tailnet, men att bevara samma värdnamnssträng bevarar inte den kryptografiska maskinidentiteten. Två nyligen autentiserade maskiner kan båda försöka använda liknande namn och ändå vara separata noder.
Testa både omstart och omdistribution av appen
Det ursprungliga problemet uppstod efter både fullständiga omstarter av operativsystemet och redigeringar av ZimaOS-appen. En korrekt lösning bör därför klara båda:
- starta om Tailscale-containern;
- redigera och distribuera appen igen utan att ändra tillståndsvolymen;
- starta om ZimaOS;
- kontrollera att samma maskin fortfarande är online i Tailscales administratörskonsol.
Om en dubblett visas efter endast en av dessa händelser, jämför vad som händer med tillståndskatalogen under just den livscykelåtgärden.
Vanliga frågor om beständigt Tailscale-tillstånd
Varför skapades en ny Tailscale-maskin efter varje omstart?
I källfallet fanns tillståndsvolymen redan, och upprepad användning av autentiseringsnyckeln var det återstående praktiska problemet.
Vilken sökväg måste bevaras?
Sökvägen som konfigureras av TS_STATE_DIR, vanligtvis /var/lib/tailscale inuti containern.
Bör TS_AUTHKEY finnas kvar i miljön för alltid?
Inte nödvändigtvis. Källanvändaren löste problemet med dubbla noder genom att ta bort det efter registreringen, och den aktuella Tailscale-versionen tillhandahåller också TS_AUTH_ONCE.
Bevarar TS_HOSTNAME nodens identitet?
Nej. Det lagrade Tailscale-maskintillståndet är det som bevarar identiteten.
