Known limitations

The guard is unconditional: it refuses the same way whether you clear the whole account or one path below it.

For the whole account that is necessary. A full clear deletes the state database and the blob cache directory outright, and a running daemon holds both open — removing them under a live mount pulls the session’s ground out from under it.

For a single path there is no such reason. Dropping the cached content of one file, or forgetting one subtree’s metadata, is an ordinary write to structures the daemon writes to all day; it has one writer and a collision policy for exactly this (Concurrency). The command refuses because of where the work happens, not what it is: cache clear does it itself, in the CLI process, opening the account’s database from a second process. The blunt guard is what keeps that second writer out of the daemon’s way.

Removing the limitation needs no new machinery. The daemon already answers a per-user socket — that is how wusel status and wusel doctor ask it what it is doing. A per-path clear handed over that socket would run inside the daemon, where it is just another write, and the mount could stay up; the file’s emblem would fall back to online-only as the eviction lands.

Until then, stop the account for the moment it takes:

wusel unpin is unaffected and works on a live mount — but it only releases a file for eviction, it does not free the space now.

Open a folder of large, never-opened documents in the file manager and the cache fills with files nobody asked for: du -sh ~/.cache/wusel grows, emblems flip from online-only to cached by themselves, and the traffic is real. PDFs are the clearest case, because rendering a thumbnail means parsing the document.

Why it happens. A VFS has exactly one signal for "the user wants this file": reads. Wusel tallies what has been read per file, and once a file is read past a floor of half a megabyte it stops serving bytes piecemeal and caches the whole file in the background. That threshold is what makes an ordinary open cheap (a MIME sniff of a few kilobytes never triggers it) and reliable (a real open crosses it at once, so the file is cached on the first open). A thumbnailer is indistinguishable from a person at this level: it opens the file and reads it, and for a PDF it reads well past the floor. The download is correct by the rule and wrong by intent.

Why the desktop cannot simply be asked. Verified on a live mount under GNOME 50 / glib 2.88: GIO reports filesystem::type: fuse and filesystem::remote: FALSE — a FUSE mount is local as far as the desktop is concerned. The one attribute that would say otherwise, filesystem::use-preview, is never delivered by the local GIO backend; only GVfs backends set it, and a kernel mount is not one. So Nautilus’s own "thumbnails for local files only" setting counts us as local, and an extension cannot decline on our behalf either: libnautilus-extension offers info, menu, column and property-page providers, and nothing that vetoes a preview. There is no cooperative channel — the decision can only be made in the filesystem.

What a fix would have to do. The filesystem knows which process is calling. A file opened by a process that is recognisably a previewer or an indexer can be refused instead of fetched, while anything already on local disk keeps opening as before. That makes Wusel judge callers by name, which is a heuristic and a policy — so it belongs in the configuration, not in silent built-in behaviour. It also has a price worth knowing in advance: GNOME records a failed thumbnailer run and does not retry it until the file’s timestamp or size changes, so a file that is pinned later can keep a generic icon until that record is cleared (rm -rf ~/.cache/thumbnails/fail/gnome-thumbnail-factory).

Today, only the indexer half has an answer: [desktop] exclude_from_indexers (on by default) makes the mount serve synthetic .trackerignore / .nomedia markers that GNOME Tracker/LocalSearch honour — see File states. Previews are not covered by it. Turning thumbnails off in the file manager works, but it is a global setting; there is no per-folder scope for it.

The used figure is real. The 1 PiB is not: it stands for "free space unknown", and it appears whenever the server names no limit for the account.

Why it happens. Wusel asks the server for the account’s quota (the WebDAV properties quota-used-bytes and quota-available-bytes). An account with no quota configured gets a truthful used figure and -3 for the available one — Nextcloud’s sentinel for "unlimited". There are two more, -1 for "not yet computed" and -2 for "unknown". None of them is a number of free bytes, so there is nothing to report.

Why not report zero. statfs(2) says undefined fields are zero, and zero free is precisely the answer that makes applications refuse to save before they have tried. So the mount advertises a large fixed amount instead — the same 1 PiB rclone’s VFS uses in the same position. The real used figure is added on top of it rather than replacing it, so df still shows what is actually stored.

What to do about it. Assign the account a quota in Nextcloud (Administration settings → Users). df then reports the server’s real numbers, within quota_revalidate_secs (Configuration) at the latest. Nothing else changes: the placeholder never limited what could be stored, it only meant the limit was unknown.

The mount says which case it is in, at info, once per fetch:

The official Nextcloud desktop client hits the same wall and sidesteps it: for an unlimited account it shows "X in use" with no total and no bar. A filesystem has no such option — df has fields that must be filled.

A folder marked end-to-end encrypted in Nextcloud’s desktop or mobile client appears in the mount with meaningless names and unreadable content: random identifiers instead of file names, ciphertext instead of documents. Nothing is broken and nothing is lost — the folder is simply not ours to read.

Why it happens. End-to-end encryption happens entirely in the client. Every file gets a symmetric key, the file names and the folder’s structure live in an encrypted metadata blob, and those keys are wrapped with a keypair whose private half never leaves the user’s own devices, protected by the twelve-word mnemonic their client showed them once. The server therefore stores precisely what WebDAV hands us: random identifiers and ciphertext. That is the feature working as designed — the operator cannot read the folder either.

What Wusel does today. Neither decrypt such a folder nor mark it. The mount shows what the server returns, which is why the result reads as corruption rather than as a locked door.

Which half is small and which is not. Recognising an encrypted folder is cheap: the server flags it in PROPFIND (nc:is-encrypted, the same property the official client reads), and our directory listing already asks for nc:-namespaced properties — so it is one property, one state, and a folder the file manager can show as locked with a notice that says why. Decrypting is a project of its own: two metadata formats, the keypair, the mnemonic-protected private key and a keystore to hold it — security code, where approximately right is worse than absent.

Meanwhile. Use a client that implements it for those folders and keep them out of the paths you rely on in the mount. Everything outside an encrypted folder is unaffected.