Why Windows Can Read a ZimaOS Share but Not Write to It
The community case points to an authentication mismatch rather than a storage failure. Android had read/write access, while Windows File Explorer was effectively reaching the share as Guest. Guest access may allow browsing or read-only access, but write operations require credentials for a ZimaOS member that has read-and-write permission on that share.
The current Shop guide for authenticated ZimaOS SMB access explains the same member-based permission model on another desktop OS. For a general cross-device overview, see NAS file-sharing guide.
Check ZimaOS Share Permissions First
- Open the target folder's sharing settings in ZimaOS.
- Confirm the intended user or member is assigned to the share.
- Set that member to read-and-write rather than read-only.
- Keep Guest access disabled if anonymous access is not needed.
This separates server-side authorization from Windows credential caching. If the member does not have write permission, changing Windows settings will not create it.
Remove the Old Guest Connection in Windows
Windows can reuse an existing SMB session or saved credential, which may cause File Explorer to reconnect without asking for the correct account. Microsoft documents Windows credentials and network authentication through Credential Manager and SMB tooling. Review the Microsoft Credential Manager documentation before deleting entries you still need.
After clearing the stale connection, reconnect to the ZimaOS share and supply the ZimaOS member username and password. Microsoft also documents SMB behavior for Windows clients in the Microsoft SMB overview.
Map the Share Explicitly
In File Explorer, use the network path supplied by ZimaOS or map the share as a network drive. If Windows still opens it as Guest, disconnect existing mappings first and reconnect with the member credentials. Avoid storing passwords in scripts or screenshots.
Where Zima Client Fits
In the original thread, write access appeared after Zima Client remounted the drive, suggesting that the client restored an authenticated path. That is a plausible explanation, but it was not proven in the thread. If you use Zima Client, verify the mounted share after sign-in and still check the underlying share permissions rather than assuming the mount alone grants write access.
The current Zima Client connectivity page describes how desktop and mobile devices connect to ZimaOS.
FAQ
Why can Android write while Windows cannot?
The two clients may be authenticating differently. A mobile file manager can hold a valid member credential while Windows is reusing a Guest session.
Should I enable Guest access to fix this?
Not if you need controlled write access. Use a member account with explicit read-and-write permission.
What if the share suddenly becomes writable again?
Check which identity Windows is using and whether Zima Client re-established the mount. Record the working configuration so the issue is reproducible if it returns.
