Ein permanenter Tailscale-Container sollte nach einem Neustart von ZimaOS oder einer Bearbeitung der Anwendung in der Tailscale-Administrationskonsole dieselbe Maschine bleiben. Im Quellthread vom September 2025 war dies nicht der Fall: Bei jedem Neustart oder jeder erneuten Bereitstellung wurde ein weiterer Tailscale-Knoten erstellt, obwohl die Compose-Datei bereits Folgendes eingebunden hatte /var/lib/tailscale in das persistente ZimaOS-AppData.
Das endgültige Ergebnis der Quelle ist wichtig, weil es die Ursache eingrenzt. Der ursprüngliche Verfasser erklärte, dass der persistente Speicher bereits korrekt eingerichtet war; das Löschen der fortlaufend bereitgestellten Umgebungsvariablen für den Authentifizierungsschlüssel war die einzige erforderliche Änderung. Danach blieb die Identität des Tailscale-Knotens erhalten.
Tailscale benötigt einen persistenten Maschinenzustand
Tailscale speichert die Knotenidentität, Schlüssel und den Verbindungsstatus in seinem Zustandsverzeichnis. In Docker wird der Pfad üblicherweise mit Folgendem konfiguriert:
TS_STATE_DIR=/var/lib/tailscaleWenn dieses Verzeichnis nur im vergänglichen Container-Dateisystem existiert, erstellt das erneute Erstellen des Containers eine neue Tailscale-Identität.
Die Quelle hatte das Zustandsverzeichnis bereits eingebunden
Die ursprüngliche Compose-Datei enthielt:
/DATA/AppData/tailscale:/var/lib/tailscalezusammen mit TS_STATE_DIR=/var/lib/tailscaleHost-Netzwerk, NET_ADMIN, NET_RAWsowie Zugriff auf /dev/net/tun. Auf dem Papier sollte das den Zustand bewahren.
Ein Authentifizierungsschlüssel dient der Registrierung, nicht unbedingt jedem Neustart
Die Compose-Datei stellte außerdem Folgendes bereit: TS_AUTHKEY bei jedem Start des Containers. Ein Community-Antwortender erklärte, dass eine erneute Authentifizierung eine neue Maschine erstellen kann, wenn der vorhandene Knotenstatus nicht wie erwartet wiederverwendet wird.
Der Antwortende schlug vor, beim ersten Start einen wiederverwendbaren, nicht kurzlebigen Authentifizierungsschlüssel zu verwenden, zu warten, bis der Knoten in der Administrationskonsole erscheint, dann die Zeile mit dem Authentifizierungsschlüssel zu entfernen und die Bereitstellung erneut durchzuführen, damit der gespeicherte Maschinenzustand als Identitätsquelle verwendet wird.
Der ursprüngliche Verfasser bestätigte, dass das Entfernen des Authentifizierungsschlüssels sein Problem behoben hat
In der abschließenden Antwort der Quelle heißt es, dass die übrigen Komponenten für die Persistenz bereits vorhanden waren und lediglich die Umgebungsvariable für den Authentifizierungsschlüssel gelöscht werden musste. Anschließend blieb der Maschinenname auch nach Neustarts erhalten.
Diese Bestätigung ist aussagekräftiger als eine allgemeine Vermutung über Berechtigungen. Bei dieser konkreten Installation war die wiederholte Authentifizierung der praktische Auslöser.
Aktuelles Tailscale stellt TS_AUTH_ONCE bereit
Moderne Tailscale-Docker-Bereitstellungen können TS_AUTH_ONCE=true. Wenn bereits ein persistenter Zustand vorhanden ist, weist dies den Container an, nicht bei jedem Start erneut eine Anmeldung zu erzwingen.
Prüfe die aktuellen Tailscale-Docker-Parameter für Status und Authentifizierung, bevor du eine Compose-Datei aus dem Jahr 2025 unverändert wiederverwendest.
Ein dediziertes Hostverzeichnis für den Status verwenden
Ein dediziertes Hostverzeichnis, etwa ein Tailscale-AppData-/Statusordner, erleichtert die Überprüfung, ob die Maschinenschlüssel eine erneute Bereitstellung überstehen. Der Antwortende im Ausgangsfall empfahl außerdem sicherzustellen, dass der Prozess, der den Tailscale-Status speichert, Schreibzugriff auf den Ordner hat.
Berechtigungen sind wichtig, da ein Volume zwar korrekt eingebunden sein kann, der Prozess seine Dateien aber dennoch nicht aktualisieren kann. In diesem Fall verhält sich Tailscale möglicherweise so, als hätte die Maschine keinen wiederverwendbaren Status.
Ephemere Authentifizierungsschlüssel für einen permanenten Server vermeiden
Tailscale unterstützt kurzlebige Knoten, die absichtlich nur vorübergehend bestehen. Das ist für kurzlebige CI-Aufträge oder wegwerfbare Container nützlich, steht aber im Gegensatz zu den Anforderungen eines permanenten ZimaOS-Servers.
Überprüfe beim Erstellen einer Berechtigung, dass sie dem vorgesehenen Lebenszyklus entspricht. Ein persistenter Heimserver sollte normalerweise dieselbe Identität behalten, bis du sie absichtlich widerrufst oder ersetzt.
TS_HOSTNAME definiert nicht die Maschinenidentität
Der Container im Ausgangsfall verwendete TS_HOSTNAME=zimaos. Diese Einstellung steuert den Anzeigenamen, der im Tailnet verwendet wird. Die Beibehaltung derselben Hostnamen-Zeichenfolge bewahrt jedoch nicht die kryptografische Maschinenidentität. Zwei neu authentifizierte Maschinen können versuchen, ähnliche Namen zu verwenden, und dennoch separate Knoten bleiben.
Neustart und erneute Bereitstellung der App testen
Das ursprüngliche Problem trat sowohl nach vollständigen Neustarts des Betriebssystems als auch nach Änderungen an der ZimaOS-App auf. Eine korrekte Lösung sollte daher beides überstehen:
- den Tailscale-Container neu starten;
- die App bearbeiten und erneut bereitstellen, ohne das Statusvolume zu ändern;
- ZimaOS neu starten;
- Überprüfe, dass dieselbe Maschine in der Tailscale-Administrationskonsole weiterhin online ist.
Wenn nach nur einem dieser Ereignisse ein Duplikat erscheint, vergleiche, was während dieses speziellen Lebenszyklusvorgangs mit dem Statusverzeichnis geschieht.
FAQ zu persistentem Tailscale
Warum wurde nach jedem Neustart eine neue Tailscale-Maschine erstellt?
Im Ausgangsfall war das Statusvolume bereits vorhanden, und die wiederholte Verwendung des Authentifizierungsschlüssels war das verbleibende praktische Problem.
Welcher Pfad muss persistent sein?
Der Pfad, der durch TS_STATE_DIR, üblicherweise /var/lib/tailscale im Container.
Sollte TS_AUTHKEY dauerhaft in der Umgebung verbleiben?
Nicht unbedingt. Der Benutzer im Ausgangsfall behob doppelte Knoten, indem er die Option nach der Registrierung entfernte. Außerdem bietet Tailscale inzwischen TS_AUTH_ONCE.
Bewahrt TS_HOSTNAME die Knotenidentität?
Nein. Der gespeicherte Tailscale-Maschinenstatus bewahrt die Identität.
