Bottom Line: A Blank ZimaOS SMB Window on Only Some Windows PCs Usually Means Session or Share Enumeration, Not a Dead NAS
The important clue is that other PCs and Macs can open the same server, and the affected Windows machines can reach the shares through ZimaClient or by typing a full share path. The server is reachable. Focus on Windows SMB credentials, cached sessions and how the server root is being enumerated.
Connect to the Exact Share First
Try:
\\192.168.x.x\ShareName
\\zima-hostname\ShareNameIf the full share path opens but \\zima-hostname\ looks empty, file access itself is working. The current ZimaOS SMB help document specifically documents blank-folder behavior around incorrect/anonymous credentials.
Clear the Windows SMB Session and Reconnect With the Right Account
net use \\192.168.x.x\ /delete /y
cmdkey /add:192.168.x.x /user:YOUR_ZIMA_USER /pass:YOUR_PASSWORD
net use \\192.168.x.x\ /USER:YOUR_ZIMA_USER YOUR_PASSWORD /PERSISTENT:YESMicrosoft documents existing SMB connection management through net use and stored credentials through cmdkey.
Why ZimaClient Can Make the Problem Disappear
In the source case, installing ZimaClient made the shares accessible on the two problematic Windows boxes. That does not prove ZimaClient “fixes Samba”; it proves that creating a fresh managed mount/path changed the Windows connection state enough to restore access.
The authenticated ZimaOS SMB guide explains the difference between discovery, credentials and actual share access.
Do Not Enable Guest Access Just to Make the Server Root Look Populated
If the share should be private, keep it authenticated and connect directly with the member account that has permission. A visible server icon in Network is only discovery; it does not guarantee Windows has a valid authenticated SMB session.
For normal client-side sharing, the NAS file-sharing guide provides the broader workflow.
