Hi, I just wanted to say that as a Linux user, I would really like if the client app for ZimaOS files also worked on linux. I understand that this OS is supposed to be about ease of use but now I’m struggling with configuring Nextcloud just to have my files sync. Hopefully the developers will do this in the future. I love everything else about ZimaOS but this one issue has been a challenge.
Is this what you are looking for? Or would this help at all?
1 Like
Totally fair feedback, and you’re not alone.
At the moment, the ZimaOS desktop sync client is Windows/macOS only, so Linux users are forced into workarounds like Nextcloud, which defeats the “simple by default” goal a bit.
Short-term Linux-friendly options (no heavy setup):
- SMB/NFS mounts – native, fast, zero extra services
- WebDAV (via
davfs2) – works with ZimaOS out of the box - rclone – reliable for one-way or scheduled syncs
- Syncthing – true Dropbox-style sync without cloud or accounts
These are lighter and often simpler than running a full Nextcloud stack just for syncing.
That said, your point is valid: a native Linux client would massively improve the experience, especially for users who already live in the Linux ecosystem. This is exactly the kind of feedback the dev team needs to prioritise it.
I’d strongly encourage posting this as a feature request, it aligns perfectly with ZimaOS’s usability goals, and you’re clearly not the only one hitting this friction point.
I’m giving SMB a try but I’m not sure how to do on-demand syncing with it. I don’t have room on my client devices to hold the data all at once.
I believe this mostly comes down to understanding the difference between access and sync, and also local vs remote use.
With SMB, there is no on-demand sync, SMB is a network share, not a sync client.
Using SMB:
- Files stay on the ZimaOS system
- Nothing is downloaded unless you open or copy a file
- There is no background syncing or offline access
- Local disk space is only used for files you actively work with
So if you don’t have room to store everything locally, I believe SMB is already behaving as intended, it provides on-demand access, not syncing.
However, I suggest keeping in mind that SMB is designed for local networks. It works very well on a LAN, but it’s not ideal for remote access and doesn’t provide file state awareness, caching, or offline use without extra complexity (VPNs, tunnels, etc.).
If what you’re really looking for is on-demand syncing, especially for use outside the local network, I suggest Nextcloud:
- Designed for secure remote access
- Has an official Linux desktop client
- Supports Virtual Files / online-only mode
- Lets you see all files but only download them when opened
- Solves the limited local storage problem cleanly
In short, I believe the practical split is:
- Local network use > SMB
- Remote access + on-demand sync > Nextcloud with Virtual Files
I suggest using SMB if your usage is strictly local, and Nextcloud if you want a true “client app” experience on Linux without filling your local disk.