If a ZimaOS server is reachable by its IP address but missing from Windows Network or macOS browsing, the server is not necessarily offline. The source case had three ZimaOS systems: two appeared automatically, while the third could still be reached normally when its full IP address was entered.
That pattern points toward discovery rather than basic connectivity. The only source reply suggested SMB/mDNS announcements, hostname conflicts, or subnet/VLAN isolation, but the original poster never returned with a confirmed diagnosis. Treat those as a prioritized checklist, not a proven 1.5 bug.
Direct IP Access Proves Basic Reachability
When \\IP\share on Windows or smb://IP on macOS works, several layers are already functioning:
- the host is online;
- IP routing to the server works;
- the SMB service is reachable;
- credentials/share permissions may be valid.
The missing browse entry is therefore a different problem from “SMB is down.”
Network Browsing Depends on Local Discovery Mechanisms
Windows and macOS do not build their network browser solely by scanning every IP address. Local discovery can involve SMB-related announcements, multicast DNS, hostnames, and platform-specific discovery services.
A server can accept direct SMB connections while failing to advertise itself in a way the client browser displays.
Confirm File Sharing Is Enabled
The community reply recommended checking that file sharing is enabled on the affected ZimaOS system. If the user has disabled SMB sharing entirely, the machine may not advertise the same way as the other servers.
Current ZimaOS documents explicit Samba share creation and per-user permissions. Use the current ZimaOS Samba sharing workflow to verify that the expected folder/share is actually active.
Give Each ZimaOS Server a Unique Hostname
Multiple servers with duplicate or ambiguous names can create discovery conflicts. Keep hostnames unique and simple, avoiding unnecessary spaces or special characters.
Even if name discovery fails, keeping a documented static/reserved IP provides a reliable fallback.
mDNS Is Helpful but Not Equivalent to SMB Reachability
The source reply suggested checking Avahi/mDNS. That is a reasonable discovery layer on Linux/macOS networks, but a successful .local name is not required for SMB over a direct IP address.
Diagnose name discovery and file-service connectivity separately.
Discovery Often Stops at VLAN or Subnet Boundaries
Multicast/broadcast discovery usually stays local unless the router deliberately reflects or relays it. A ZimaOS server on another VLAN can be fully routable by IP while never appearing in the local browse list.
Check the server IP, subnet mask, VLAN, and client network before restarting services.
The Client Browser Can Cache Network Entries
Windows Explorer and Finder can retain stale discovery results. Test direct hostname/IP access, restart the client discovery session when practical, and compare from another computer before changing ZimaOS configuration.
Compare the Working and Missing ZimaOS Servers
Because the source had two working servers and one missing server, the strongest diagnostic is a side-by-side comparison:
- ZimaOS version;
- hostname;
- IP/subnet/VLAN;
- SMB sharing status;
- network interface;
- client credentials/share configuration.
Do Not Call This a Confirmed ZimaOS 1.5 Regression
No IceWhale staff reply or user follow-up proves that version 1.5 caused the discovery difference. Current ZimaOS is much newer, so reproduce the symptom on the current release before applying service-level fixes.
Network Discovery FAQ
If SMB works by IP, is the server offline?
No. That strongly suggests basic network and SMB reachability are working.
Can VLANs break automatic network browsing while direct IP still works?
Yes. Discovery traffic often does not cross subnet/VLAN boundaries automatically.
Was the source root cause confirmed?
No. The thread contains one community troubleshooting reply and no final user verification.
