Platform support

This page is the authoritative answer. Where another page mentions a platform, it links here rather than restating it.

Operating systems

System	Status	Notes
Linux	supported	The mount is a FUSE filesystem (libfuse3). This is the reference platform — the most complete and most heavily tested.
macOS	experimental	A native File Provider extension (not FUSE): files appear in Finder, macOS’s own indicators show downloaded vs online-only, an extra emblem marks items kept offline, and pin / unpin run from the Finder context menu. It is a macOS app bundle with a sandboxed File Provider extension, bridged to the same engine Linux uses over the wusel-ipc socket. Treat it as experimental: there is no packaged build yet — to try it you build the Xcode project in the repository yourself — and a signed App Store build is the goal (roadmap). Building the engine from a Mac is Develop on macOS.
Windows	not supported	Not built yet — planned as a native Cloud Filter frontend, not FUSE. See the roadmap.

System

Status

Notes

Linux

supported

The mount is a FUSE filesystem (libfuse3). This is the reference platform — the most complete and most heavily tested.

macOS

experimental

A native File Provider extension (not FUSE): files appear in Finder, macOS’s own indicators show downloaded vs online-only, an extra emblem marks items kept offline, and pin / unpin run from the Finder context menu. It is a macOS app bundle with a sandboxed File Provider extension, bridged to the same engine Linux uses over the wusel-ipc socket. Treat it as experimental: there is no packaged build yet — to try it you build the Xcode project in the repository yourself — and a signed App Store build is the goal (roadmap). Building the engine from a Mac is Develop on macOS.

Windows

not supported

Not built yet — planned as a native Cloud Filter frontend, not FUSE. See the roadmap.

The macOS frontend (File Provider) is here now, as experimental work; the Windows one (Cloud Filter) is still ahead. Each is an adapter over the same facade — deliberately not a FUSE-compatibility shim, but the native framework. See the roadmap for the order, and Portability for what has to stay true for that to remain affordable.

Running the mount inside a podman container on macOS or Windows is a development and test path, not a product. The mount then lives inside podman’s Linux VM; it is not a drive on the host.

Desktops

The mount itself does not care which desktop you use, or whether you use one at all — it works the same on GNOME, on KDE and on a server with no graphical session.

The desktop integration is a different matter. It is GNOME and Nautilus today, and nothing else. On any other desktop you get the mount plus notifications, and none of the rest.

Desktop Status What you get

Desktop	Status	What you get
GNOME / Nautilus	supported	Everything: the Wusel (Nextcloud) sidebar entry with live sync status, per-file emblems, the Make Available Offline / Free Up Space menu, Nextcloud results in the Activities search, and native notifications.
KDE Plasma / Dolphin	partial	Notifications work — they are freedesktop, not GNOME. Dolphin consumes no `libcloudproviders`, so there is no sidebar entry, and there is no Dolphin plugin yet, so there are no emblems. A `KOverlayIconPlugin` is a roadmap item.
Nemo, Thunar, others	partial	As KDE: notifications only. Each would need its own extension reading the same file-state attribute.
No desktop (server, SSH)	supported	The mount and the CLI. The D-Bus channels disable themselves silently — but notices still have a way out here: a notify hook runs a script for each one and needs no session bus. Note that a headless machine usually has no unlocked keyring either — see Credentials and trust.

GNOME / Nautilus

supported

Everything: the Wusel (Nextcloud) sidebar entry with live sync status, per-file emblems, the Make Available Offline / Free Up Space menu, Nextcloud results in the Activities search, and native notifications.

KDE Plasma / Dolphin

partial

Notifications work — they are freedesktop, not GNOME. Dolphin consumes no libcloudproviders, so there is no sidebar entry, and there is no Dolphin plugin yet, so there are no emblems. A KOverlayIconPlugin is a roadmap item.

Nemo, Thunar, others

partial

As KDE: notifications only. Each would need its own extension reading the same file-state attribute.

No desktop (server, SSH)

supported

The mount and the CLI. The D-Bus channels disable themselves silently — but notices still have a way out here: a notify hook runs a script for each one and needs no session bus. Note that a headless machine usually has no unlocked keyring either — see Credentials and trust.

Distributions

Distribution Status Notes

Distribution	Status	Notes
Fedora 44	reference setup	Where development happens and where the desktop integration is verified by hand. A published RPM.
Debian 13 (trixie)	tested	A published `.deb`. Also used headless in the containerised FUSE test suite.
Ubuntu	expected to work	Releases close to Debian 13. On 24.04 LTS and older, expect the published `.deb` not to run — build from source instead.
Arch Linux	recipe only	A `PKGBUILD` in the repository, not yet on the AUR, not built in CI.
Everything else	build from source	Nothing distribution-specific stands in the way; there is simply no package.

Fedora 44

reference setup

Where development happens and where the desktop integration is verified by hand. A published RPM.

Debian 13 (trixie)

tested

A published .deb. Also used headless in the containerised FUSE test suite.

Ubuntu

expected to work

Releases close to Debian 13. On 24.04 LTS and older, expect the published .deb not to run — build from source instead.

Arch Linux

recipe only

A PKGBUILD in the repository, not yet on the AUR, not built in CI.

Everything else

build from source

Nothing distribution-specific stands in the way; there is simply no package.

Nextcloud versions

Every night, Wusel is tested against three real Nextcloud servers, one per maintained major — each a full run of mount, read, write, upload and three-way merge, not a mocked API. Which three those are is not written down anywhere, including here: the workflow asks Docker Hub which majors are current and takes the newest three, so a new Nextcloud release enters the matrix by itself.

The run is nightly but gated: it only actually executes when our own code or one of the three server images has changed since the last successful run, so a docs-only day costs nothing while a Nextcloud patch release re-arms it.

Version	Status
the newest maintained major	Binding. If it breaks, the build goes red.
the two before it	Tested, and the result is written into the run summary — but a failure there never turns the build red and never opens an issue. A red build has to mean "we are broken", not "somebody still runs an old server".
anything older	Outside Nextcloud’s own maintenance, and not tested.

Version

Status

the newest maintained major

Binding. If it breaks, the build goes red.

the two before it

Tested, and the result is written into the run summary — but a failure there never turns the build red and never opens an issue. A red build has to mean "we are broken", not "somebody still runs an old server".

anything older

Outside Nextcloud’s own maintenance, and not tested.

Which majors ran, and how each fared, is in the summary of the latest E2E run.

Wusel targets Nextcloud specifically, not "any WebDAV server". Which parts of that conversation are standards and which are Nextcloud’s own — and what happens when one of the latter is absent — is in Compatibility and stability.