A ZVM guest can have a valid LAN address and still fail to reach services running on the ZimaOS host itself. That was the core problem in this thread. With the VM set to Bridge to eth0, the guest could participate on the LAN but reported no route to the host. Zima-Giorgio recommended switching the VM to NAT when the goal was to connect back to ZimaOS shares.
The source also shows that “network route” and “SMB permission” are separate problems. One later user switched to NAT and reached the login dialog but still could not access the RAID share with several accounts. That authentication/storage issue should not be confused with the bridge-mode host-isolation problem.
Bridge Mode Gave the VM Normal LAN Reachability
The original user selected Bridge to eth0 because they wanted the VM to behave like another device on the local network. In that mode, the VM could obtain a LAN address and communicate with other LAN systems.
The missing path was specifically VM ↔ ZimaOS host communication.
Zima-Giorgio Recommended NAT for Host Access
IceWhale's Zima-Giorgio told the user to shut down the VM and change networking from Bridge to NAT. In a follow-up, he described his experience as a tradeoff: NAT allows access to the host, while bridge provides access to other LAN devices.
That is official support guidance from the 2025 source thread, not a generic statement about every libvirt topology.
Later Community Reports Still Matched macvtap Host Isolation
In May-June 2026, another community thread described the same pattern: a bridged VM received a normal LAN IP, could reach other LAN devices, but could not ARP or connect to the ZimaOS host. Switching to NAT immediately restored host connectivity.
The users suspected ZVM's “Bridge to eth0” path was implemented with macvtap, whose host-isolation behavior is well known. The public thread did not include an IceWhale confirmation of the exact backend, so macvtap should remain a strong community explanation rather than an official implementation claim.
SMB Login Problems Are a Separate Layer
One participant switched to NAT and could finally reach the ZimaCube login dialog, but SMB accounts still behaved inconsistently. Their main account could browse some host paths while RAID access failed, and other accounts returned permission errors.
Once basic IP reachability exists, troubleshoot the SMB share account and permissions separately.
Current ZimaOS documents per-user Samba sharing and read/read-write permissions. Use the current ZimaOS Samba multi-user permission model when a VM can reach the server but authentication or access still fails.
Ubuntu's File Sharing and Remote Login Entries Are Not the Same Protocol
The source user noticed Ubuntu showing “ZimaCube (File Sharing)” and “ZimaCube (Remote Login).” Their password manager also showed an sftp:// connection for the latter.
SFTP over SSH and SMB are different services. A successful SFTP login does not prove SMB permissions are correct, and an SMB share should be tested with an SMB URL or network-share browser rather than the SSH entry.
A Community User Built a Static-Route Workaround for Bridge Mode
Another participant kept the VM bridged and used a third Debian server as a router between the VM and host, then added static routes on both endpoints. They reported it worked but called the result “not pretty.”
Those Linux routing commands were community experimentation, not IceWhale's recommended ZVM design. The extra router also becomes a throughput bottleneck and another point of failure.
Choose Networking Based on the Actual VM Role
- VM mainly needs to reach ZimaOS-hosted services or shares: NAT is the source-supported first test.
- VM mainly needs to behave like a separate LAN device: Bridge can provide the normal LAN address.
- VM needs both host and LAN reachability: test the current ZVM release carefully; the historical source shows this was the unresolved gap.
Current ZimaOS Network Settings Do Not Document a ZVM br0 Workflow
Current public ZimaOS networking documentation covers physical interfaces, DHCP/manual IP configuration, and remote access. It does not publish a supported procedure for creating a custom host bridge specifically to bypass the ZVM host-isolation behavior.
Use the current ZimaOS networking model before editing host routes or NetworkManager files manually.
ZVM Host Access FAQ
Did NAT allow the source VM to reach the ZimaOS host?
Yes. Users reported that changing to NAT removed the no-route-to-host barrier.
Did NAT automatically fix SMB permissions?
No. One user reached the login dialog but still had separate share-permission problems.
Was the third-server routing workaround official?
No. It was a community workaround for users who wanted to keep bridge mode.
