Community Solution

Mount a Remote SMB Share on ZimaOS: Why Docker Tailscale Does Not Extend the Host Network

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.

A VPN container can be connected to a remote network while the ZimaOS host remains completely unaware of that route. That was the problem in this September 2025 source thread. The user's Tailscale container successfully joined the tailnet, but ZimaOS itself—and therefore the Files app and host SMB-mount workflow—could not reach the remote CasaOS server through the container's network namespace.

The user solved the practical backup problem by changing the architecture rather than forcing the Tailscale container to become a host VPN. They joined the remote CasaOS server to the ZeroTier network associated with ZimaOS and reported that SMB access then worked well.

The Original Topology Had Two Remote Servers

The source setup was:

  • ZimaBlade running ZimaOS as the source machine;
  • remote server running CasaOS as the SMB backup target;
  • Tailscale connecting both sites.

When both machines previously ran CasaOS, the user had installed Tailscale directly on the hosts and mounted the remote SMB share normally.

The Tailscale Container Joined the Tailnet, but ZimaOS Did Not

On ZimaOS, the user ran Tailscale in Docker. That created connectivity for the Tailscale container itself. It did not automatically add Tailscale routes or addresses to the ZimaOS host network namespace.

Therefore the Files app could not simply browse an SMB server that was reachable only from inside the Tailscale container.

This Is a Network-Namespace Boundary, Not an SMB Password Problem

A Docker container normally has its own interfaces, routes, and firewall context. Even if the container can ping a remote tailnet address, host applications do not inherit those routes unless the VPN has been deliberately integrated with host networking, routing, or a proxy architecture.

Changing SMB credentials would not solve that missing route.

The User Switched the Remote CasaOS Server to ZeroTier

After more research, the original poster installed ZeroTier on the remote CasaOS server and joined it to the virtual network used by ZimaOS. They then said the remote server could access the SMB share and that the solution worked well.

The exact installer command in the forum was user-provided community guidance. The reusable architecture is more important than copying that one-line install script.

Current ZimaOS Remote Access Is Built Around a ZeroTier-Based Virtual Network

Current IceWhale documentation describes the ZimaOS Remote Login/Network ID as a ZeroTier network identity. ZimaClient uses this virtual network for encrypted remote connectivity.

That makes the source user's solution less of an odd workaround than it might appear: instead of trying to export a Docker Tailscale route to the host, the remote NAS joins the virtual network ZimaOS already uses at the host level.

IceWhale Now Documents the Same Pattern with Other NAS Platforms

Current ZimaOS documentation for QNAP synchronization tells users to obtain the ZimaOS Network ID, install ZeroTier on the QNAP side, and join that ID before creating a cross-network sync task.

Use the current cross-NAS ZeroTier network pattern as a supported architectural reference.

A Host-Level Tailscale Option Is a Different Solution

Later community projects have packaged Tailscale as a native ZimaOS systemd-sysext, specifically to give the host a real TUN interface and support host-level routing. That can address the original namespace limitation, but it is community software rather than a first-party ZimaOS Tailscale feature.

If the goal is only remote SMB backup, joining the remote server to the existing ZimaOS virtual network may be simpler than installing a new host-level VPN extension.

Host-Level Reachability Must Exist Before Files Can Mount SMB

Whichever overlay network you choose, the ZimaOS host needs to be able to route to the remote SMB server address. Only then do SMB share name, username, password, and permissions become the next troubleshooting layer.

Treat the Remote SMB Destination as Part of the Backup Security Boundary

A backup share reachable over an overlay network should still require authentication and should expose only the folders the backup workflow needs. Avoid making the entire remote server writable simply because the traffic is encrypted.

Remote SMB over Overlay Networks FAQ

Why could the Tailscale container reach the remote server while ZimaOS Files could not?

The container had its own network namespace and routes; the ZimaOS host did not automatically inherit them.

What did the original poster use instead?

They joined the remote CasaOS server to the ZeroTier network used by ZimaOS and reported that it worked well.

Does current ZimaOS use ZeroTier for remote networking?

Current IceWhale documentation describes the Remote Login Network ID and cross-NAS workflows using ZeroTier-based virtual networking.