Den här tråden från oktober 2025 beskriver två fungerande sätt att få Tailscale-appen registrerad på ZimaOS: en interaktiv inloggnings-URL som hämtas från containerns terminal samt ett arbetsflöde med en autentiseringsnyckel som Zima-Giorgio länkade till från en tidigare löst tråd. Ursprungspostaren såg först ingenting när terminalmetoden användes, men följde sedan instruktionerna för autentiseringsnyckeln och markerade uttryckligen problemet som löst.
En komplett modern installation behöver ytterligare en del som den korta källdiskussionen inte tog upp: Tailscales tillståndskatalog måste vara beständig så att noden förblir samma maskin efter omstarter av ZimaOS eller appen.
Bekräfta först att Tailscale-containern faktiskt körs
Autentisering hjälper bara om containern har startat korrekt och kan nå Tailscales kontrollplan. Om appen är stoppad, startar om upprepade gånger eller saknar nödvändiga nätverksfunktioner löser en inloggnings-URL inte körningsproblemet.
Öppna applikationsterminalen eller loggarna och bekräfta att Tailscale-processen körs innan du ändrar autentiseringsuppgifterna.
Metod 1: Använd inloggnings-URL:en från containern
En deltagare i communityt öppnade Tailscale-appens terminal och körde:
tailscale statusEftersom noden inte var inloggad returnerade Tailscale en URL för webbläsarautentisering.
Öppna URL:en på en betrodd enhet där du redan är inloggad på rätt Tailscale-konto.
Metod 2: Använd en autentiseringsnyckel i appens konfiguration
Zima-Giorgio länkade till en tidigare löst tråd där användaren skapade en autentiseringsnyckel och lade in den i Tailscale-appens miljökonfiguration. Ursprungspostaren i den här tråden sade senare att problemet löstes genom att följa de instruktionerna.
Skapa dina egna autentiseringsuppgifter i Tailscales administratörskonsol. Autentiseringsnycklar ska hanteras som lösenord: publicera dem inte, återanvänd inte någon annans värde och lagra dem inte i skärmbilder.
Källans användare behövde rätt Tailscale-behörighet för att skapa nyckeln
Det sista svaret i källan säger att användaren, efter att ha följt instruktionerna för att konfigurera kontot korrekt, kunde skapa nyckeln och slutföra installationen. Det är en användbar påminnelse om att ett saknat alternativ för autentiseringsnyckel kan bero på kontots roll i stället för på ett problem med ZimaOS-applikationen.
Kontrollera att noden visas i Tailscales administratörskonsol
När noden visas testar du åtkomsten från en annan enhet i tailnet-nätverket i stället för att anta att en onlinestatus innebär att alla ZimaOS-tjänster är nåbara.
Gör maskinens tillstånd beständigt
Aktuella Tailscale Docker-distributioner använder TS_STATE_DIR för att ange var tailscaled lagrar identitets- och inloggningstillstånd. Den katalogen bör mappas till beständig lagring på ZimaOS.
Utan beständigt tillstånd kan en återskapad container uppfattas som en helt ny maskin av Tailscale, även om värdnamnet är oförändrat.
Gå igenom de aktuella alternativen för Tailscale Docker-autentisering och tillstånd innan du färdigställer en permanent ZimaOS-nod.
Använd TS_AUTH_ONCE för automatiserad registrering med beständigt tillstånd
Om en autentiseringsnyckel avsiktligt behålls i containerns konfiguration kan aktuella versioner av Tailscale använda TS_AUTH_ONCE=true. Det innebär att containern endast autentiseras när den inte redan har ett giltigt tillstånd.
Det förhindrar att en distribution beter sig som en ny maskin bara för att tjänsten startas om.
Vilken metod är bäst?
För en personlig server är en interaktiv inloggnings-URL enkel att granska eftersom ingen återanvändbar nyckel behöver finnas kvar i appens konfiguration. En autentiseringsnyckel är praktisk för automatiserade distributioner, särskilt i kombination med beständigt tillstånd och engångsautentisering.
Båda metoderna är giltiga. Källtråden visar att en användare lyckades med en autentiseringsnyckel medan en annan deltagare lyckades med inloggnings-URL:en.
Vanliga frågor om Tailscale-konfiguration
Kan jag ansluta till Tailscale utan en autentiseringsnyckel?
Ja. Tråden visar en webbläsar-URL för inloggning som genererades från applikationsterminalen.
Löste ursprungspostaren konfigurationen?
Ja. Personen sade senare att arbetsflödet med autentiseringsnyckeln löste problemet.
Varför kan noden visas igen som en ny maskin efter en omstart?
Tillståndskatalogen kanske inte är beständig, eller så tvingar containern fram en ny autentisering.
Bör en återanvändbar autentiseringsnyckel synas i skärmbilder eller foruminlägg?
Nej. Hantera den som en hemlig autentiseringsuppgift.
