Ein VPN-Container kann mit einem entfernten Netzwerk verbunden sein, während der ZimaOS-Host von dieser Route überhaupt nichts mitbekommt. Genau das war das Problem im Ausgangsthread vom September 2025. Der Tailscale-Container des Benutzers war erfolgreich dem Tailnet beigetreten, aber ZimaOS selbst – und damit die Dateien-App sowie der SMB-Einhängeworkflow des Hosts – konnte den entfernten CasaOS-Server nicht über den Netzwerk-Namespace des Containers erreichen.
Der Benutzer löste das praktische Backup-Problem, indem er die Architektur änderte, anstatt den Tailscale-Container zum Host-VPN zu machen. Er band den entfernten CasaOS-Server in das mit ZimaOS verbundene ZeroTier-Netzwerk ein und berichtete, dass der SMB-Zugriff anschließend problemlos funktionierte.
Die ursprüngliche Topologie umfasste zwei entfernte Server
Die Ausgangskonfiguration bestand aus:
- einem ZimaBlade mit ZimaOS als Quellgerät;
- einem entfernten Server mit CasaOS als SMB-Backup-Ziel;
- Tailscale zur Verbindung beider Standorte.
Als beide Geräte zuvor noch CasaOS verwendeten, hatte der Benutzer Tailscale direkt auf den Hosts installiert und die entfernte SMB-Freigabe ganz normal eingebunden.
Der Tailscale-Container war dem Tailnet beigetreten, ZimaOS jedoch nicht
Unter ZimaOS führte der Benutzer Tailscale in Docker aus. Dadurch erhielt der Tailscale-Container selbst Konnektivität. Tailscale-Routen oder -Adressen wurden jedoch nicht automatisch in den Netzwerk-Namespace des ZimaOS-Hosts übernommen.
Deshalb konnte die Dateien-App einen SMB-Server, der nur innerhalb des Tailscale-Containers erreichbar war, nicht einfach durchsuchen.
Dies ist eine Grenze zwischen Netzwerk-Namespaces und kein SMB-Passwortproblem
Ein Docker-Container verfügt normalerweise über eigene Schnittstellen, Routen und Firewall-Regeln. Selbst wenn der Container eine entfernte Tailnet-Adresse anpingen kann, übernehmen Host-Anwendungen diese Routen nicht automatisch, sofern das VPN nicht gezielt in das Host-Netzwerk, das Routing oder eine Proxy-Architektur integriert wurde.
Das Ändern der SMB-Zugangsdaten würde diese fehlende Route nicht beheben.
Der Benutzer wechselte für den entfernten CasaOS-Server zu ZeroTier
Nach weiteren Recherchen installierte der ursprüngliche Verfasser ZeroTier auf dem entfernten CasaOS-Server und band ihn in das von ZimaOS verwendete virtuelle Netzwerk ein. Anschließend teilte er mit, dass der entfernte Server auf die SMB-Freigabe zugreifen konnte und die Lösung gut funktionierte.
Der genaue Installationsbefehl im Forum stammte aus einer von Benutzern bereitgestellten Community-Anleitung. Die wiederverwendbare Architektur ist wichtiger, als genau dieses einzeilige Installationsskript zu kopieren.
Der aktuelle Fernzugriff von ZimaOS basiert auf einem ZeroTier-basierten virtuellen Netzwerk
Die aktuelle Dokumentation von IceWhale beschreibt die ZimaOS-Remote-Anmeldung bzw. Network ID als eine ZeroTier-Netzwerkidentität. ZimaClient verwendet dieses virtuelle Netzwerk für verschlüsselte Fernverbindungen.
Dadurch wirkt die Lösung des Benutzers weniger wie ein ungewöhnlicher Workaround: Statt zu versuchen, eine Docker-Tailscale-Route an den Host weiterzugeben, wird das entfernte NAS in das virtuelle Netzwerk eingebunden, das ZimaOS bereits auf Host-Ebene verwendet.
IceWhale dokumentiert dieses Muster inzwischen auch für andere NAS-Plattformen
In der aktuellen ZimaOS-Dokumentation zur Synchronisierung mit QNAP werden Benutzer aufgefordert, die ZimaOS Network ID abzurufen, ZeroTier auf der QNAP-Seite zu installieren und dieser ID beizutreten, bevor eine netzwerkübergreifende Synchronisierungsaufgabe erstellt wird.
Verwenden Sie das aktuelle ZeroTier-Netzwerkmuster für die Verbindung mehrerer NAS als unterstützte architektonische Referenz.
Eine hostbasierte Tailscale-Option ist eine andere Lösung
Spätere Community-Projekte haben Tailscale als natives ZimaOS-systemd-sysext gebündelt, um dem Host eine echte TUN-Schnittstelle bereitzustellen und hostbasiertes Routing zu ermöglichen. Damit lässt sich die ursprüngliche Namespace-Einschränkung beheben, es handelt sich jedoch um Community-Software und nicht um eine offizielle Tailscale-Funktion von ZimaOS.
Wenn es nur um ein entferntes SMB-Backup geht, kann es einfacher sein, den entfernten Server in das bestehende virtuelle ZimaOS-Netzwerk einzubinden, als eine neue hostbasierte VPN-Erweiterung zu installieren.
Die Erreichbarkeit auf Host-Ebene muss vorhanden sein, bevor die Dateien-App SMB einbinden kann
Unabhängig vom gewählten Overlay-Netzwerk muss der ZimaOS-Host den entfernten SMB-Server erreichen und zu dessen Adresse routen können. Erst danach werden der Name der SMB-Freigabe, Benutzername, Passwort und Berechtigungen zur nächsten Fehlerbehebungsebene.
Behandeln Sie das entfernte SMB-Ziel als Teil der Backup-Sicherheitsgrenze
Eine über ein Overlay-Netzwerk erreichbare Backup-Freigabe sollte weiterhin eine Authentifizierung erfordern und nur die Ordner bereitstellen, die der Backup-Workflow benötigt. Vermeiden Sie es, den gesamten entfernten Server beschreibbar zu machen, nur weil der Datenverkehr verschlüsselt ist.
FAQ zu entferntem SMB über Overlay-Netzwerke
Warum konnte der Tailscale-Container den entfernten Server erreichen, die ZimaOS-Dateien-App jedoch nicht?
Der Container verfügte über einen eigenen Netzwerk-Namespace und eigene Routen; der ZimaOS-Host übernahm diese nicht automatisch.
Welche Alternative verwendete der ursprüngliche Verfasser?
Er band den entfernten CasaOS-Server in das von ZimaOS verwendete ZeroTier-Netzwerk ein und berichtete, dass dies gut funktionierte.
Verwendet das aktuelle ZimaOS ZeroTier für den Fernzugriff?
Die aktuelle Dokumentation von IceWhale beschreibt die Remote-Login-Network-ID und netzwerkübergreifende NAS-Workflows mithilfe einer auf ZeroTier basierenden virtuellen Vernetzung.
