Gemenskapslösning

Montera en fjärransluten SMB-delning på ZimaOS: Varför Docker Tailscale inte utökar värdnätverket

A September 2025 thread where a ZimaOS source server could run Tailscale only in Docker, so the host and Files app could not see the remote CasaOS SMB server through that container network. The user changed the design and joined the remote CasaOS server to the ZeroTier network used by ZimaOS, which they reported worked well.

En VPN-container kan ansluta till ett fjärrnätverk medan ZimaOS-värden förblir helt ovetande om den routen. Det var problemet i den här källtråden från september 2025. Användarens Tailscale-container anslöt framgångsrikt till tailnet, men ZimaOS självt – och därmed appen Filer samt värdens arbetsflöde för SMB-montering – kunde inte nå den fjärranslutna CasaOS-servern via containerns nätverksnamnrymd.

Användaren löste det praktiska säkerhetskopieringsproblemet genom att ändra arkitekturen i stället för att försöka få Tailscale-containern att fungera som ett VPN för värden. De anslöt den fjärranslutna CasaOS-servern till det ZeroTier-nätverk som är kopplat till ZimaOS och rapporterade att SMB-åtkomst därefter fungerade bra.

Den ursprungliga topologin hade två fjärrservrar

Källkonfigurationen var:

  • ZimaBlade med ZimaOS som källmaskin;
  • fjärrserver med CasaOS som mål för SMB-säkerhetskopiering;
  • Tailscale som anslöt de båda platserna.

När båda maskinerna tidigare körde CasaOS hade användaren installerat Tailscale direkt på värdarna och monterat den fjärranslutna SMB-resursen på normalt sätt.

Tailscale-containern anslöt till tailnet, men inte ZimaOS

I ZimaOS körde användaren Tailscale i Docker. Det skapade anslutning för själva Tailscale-containern. Det lade inte automatiskt till Tailscale-rutter eller adresser i ZimaOS-värdens nätverksnamnrymd.

Därför kunde appen Filer inte bara bläddra till en SMB-server som endast var åtkomlig från Tailscale-containern.

Det här är en gräns mellan nätverksnamnrymder, inte ett problem med SMB-lösenord

En Docker-container har normalt egna gränssnitt, rutter och brandväggsregler. Även om containern kan pinga en fjärradress i tailnet ärver värdprogram inte dessa rutter, såvida VPN-anslutningen inte uttryckligen har integrerats med värdnätverk, routing eller en proxyarkitektur.

Att ändra SMB-autentiseringsuppgifter skulle inte lösa den saknade routen.

Användaren bytte den fjärranslutna CasaOS-servern till ZeroTier

Efter mer efterforskning installerade den ursprungliga skribenten ZeroTier på den fjärranslutna CasaOS-servern och anslöt den till det virtuella nätverk som används av ZimaOS. Därefter uppgav de att fjärrservern kunde komma åt SMB-resursen och att lösningen fungerade bra.

Det exakta installationskommandot i forumet var användarbidragen community-vägledning. Den återanvändbara arkitekturen är viktigare än att kopiera just det enradiga installationsskriptet.

Fjärråtkomst i dagens ZimaOS bygger på ett ZeroTier-baserat virtuellt nätverk

Aktuell dokumentation från IceWhale beskriver ZimaOS Remote Login/Network ID som en ZeroTier-nätverksidentitet. ZimaClient använder detta virtuella nätverk för krypterad fjärranslutning.

Det gör källanvändarens lösning mindre av en udda kringlösning än den kanske först verkar: i stället för att försöka exportera en Docker-baserad Tailscale-rutt till värden ansluter den fjärranslutna NAS-enheten till det virtuella nätverk som ZimaOS redan använder på värdnivå.

IceWhale dokumenterar nu samma mönster med andra NAS-plattformar

Aktuell ZimaOS-dokumentation för synkronisering med QNAP instruerar användare att hämta ZimaOS Network ID, installera ZeroTier på QNAP-sidan och ansluta den till detta ID innan en synkroniseringsuppgift mellan nätverk skapas.

Använd det aktuella ZeroTier-mönstret för nätverk mellan NAS-enheter som en stödd arkitektonisk referens.

Ett Tailscale-alternativ på värdnivå är en annan lösning

Senare community-projekt har paketerat Tailscale som en inbyggd ZimaOS-systemd-sysext, specifikt för att ge värden ett riktigt TUN-gränssnitt och stödja routing på värdnivå. Det kan hantera den ursprungliga begränsningen mellan namnrymder, men det är community-programvara och inte en Tailscale-funktion från ZimaOS förstapart.

Om målet endast är fjärrsäkerhetskopiering via SMB kan det vara enklare att ansluta fjärrservern till det befintliga virtuella ZimaOS-nätverket än att installera ett nytt VPN-tillägg på värdnivå.

Åtkomlighet på värdnivå måste finnas innan Filer kan montera SMB

Oavsett vilket overlay-nätverk du väljer måste ZimaOS-värden kunna routa till den fjärranslutna SMB-serverns adress. Först därefter blir SMB-resursens namn, användarnamn, lösenord och behörigheter nästa felsökningsnivå.

Behandla den fjärranslutna SMB-destinationen som en del av säkerhetsgränsen för säkerhetskopieringen

En säkerhetskopieringsresurs som är åtkomlig via ett overlay-nätverk bör fortfarande kräva autentisering och endast exponera de mappar som säkerhetskopieringsarbetsflödet behöver. Undvik att göra hela fjärrservern skrivbar bara för att trafiken är krypterad.

Vanliga frågor om fjärr-SMB via overlay-nätverk

Varför kunde Tailscale-containern nå fjärrservern medan Filer i ZimaOS inte kunde det?

Containern hade sin egen nätverksnamnrymd och egna rutter; ZimaOS-värden ärvde dem inte automatiskt.

Vad använde den ursprungliga skribenten i stället?

De anslöt den fjärranslutna CasaOS-servern till det ZeroTier-nätverk som används av ZimaOS och uppgav att det fungerade bra.

Använder dagens ZimaOS ZeroTier för fjärrnätverk?

Aktuell dokumentation från IceWhale beskriver Remote Login Network ID och arbetsflöden mellan NAS-enheter med ZeroTier-baserade virtuella nätverk.