Mounting Encrypted Cloud Storage on Linux: rclone, FUSE, WebDAV, and What Actually Shows Up in Nautilus

The short version

To mount encrypted cloud storage as a local filesystem on Linux, stack two layers: an rclone crypt remote for the encryption, then rclone mount over FUSE to expose it as a directory. Install fuse3, point the mount at a folder under your home, and the path behaves like any other — cp and rsync work, your editor opens files in place, nothing knows it's talking to a bucket. Getting it to show as a tidy drive in Nautilus or Dolphin is a separate, finickier problem. Here's the whole chain, including where it breaks.

Why FUSE is the right primitive (and the native plugins aren't)

FUSE — Filesystem in Userspace — lets a normal program present itself as a mounted filesystem. The kernel routes read(), write(), and readdir() to a userspace daemon instead of a block device. rclone speaks FUSE directly, which is why rclone mount behaves the same against Google Drive, an S3 bucket, or a crypt-wrapped remote.

The tempting alternative is a file-manager plugin: GNOME's online-accounts integration, a KDE network resource, a GVfs backend. Skip them for encrypted storage. They cover a fixed set of protocols, none of which is rclone's crypt format, and they're the first thing to break on a distro upgrade. A FUSE mount is protocol-agnostic and outlives whatever desktop environment you're on this year. Every path below assumes FUSE.

Layer one: rclone crypt

rclone crypt is a wrapping remote. You configure a base remote (any of rclone's 70-plus backends), then a crypt remote that sits on top and transparently encrypts filenames, directory names, and content on the way out, decrypting on the way in. Your provider sees ciphertext blobs and scrambled names like p0e52nreeaj0a5ea7s64m4j72s/qgm4avr35m5loi1th53ato71v0, never the plaintext.

Be precise about the crypto, because this is where guides overclaim. rclone crypt derives its key with scrypt (N=16384, r=8, p=1) and encrypts content with NaCl SecretBox — XSalsa20-Poly1305 — in 64 KiB chunks, each chunk authenticated. That's a solid, modern AEAD construction. It is not AES-256-GCM, and it is not Argon2id for key stretching. If a tutorial tells you rclone crypt uses "AES-256," it's wrong; the maintainers picked the libsodium stack on purpose. Setup looks like this:

rclone config        # create a base remote, then a "crypt" remote over it
rclone copy ~/Documents secret:    # writes encrypted blobs to the backend

Two real footguns. Lose the crypt password or salt and the data is gone — there is no recovery path, which is the honest cost of zero-knowledge. Second, filename encryption inflates path lengths; on backends with a short path limit, a deeply nested tree can fail to write. Stick with the standard base32 name encoding unless you've confirmed your backend tolerates base64.

Layer two: rclone mount over FUSE

With the crypt remote in place, mount it. Install FUSE 3 first:

sudo apt install fuse3            # Debian/Ubuntu; dnf on Fedora, pacman on Arch
mkdir -p ~/mnt/secret
rclone mount secret: ~/mnt/secret --vfs-cache-mode writes --daemon

--vfs-cache-mode writes is not optional for real work. Without it, any application that opens a file, seeks backwards, and rewrites — which is basically every office suite and a lot of editors — fails, because a naive cloud mount can't seek into an object it's streaming. With the writes cache, rclone stages changes on local disk and flushes them back. For heavy random I/O, step up to --vfs-cache-mode full.

Now the part most tutorials skip. By default a FUSE mount is visible only to the user who created it. Root and other accounts get permission-denied, which quietly breaks Docker bind mounts and anything running as a service. The fix is the --allow-other flag, and that flag is refused until you uncomment user_allow_other in /etc/fuse.conf:

# /etc/fuse.conf
user_allow_other

Then add --allow-other to the mount command. Only do this if you genuinely need cross-user access — it widens who can read the decrypted view.

Will it actually show up in Nautilus or Dolphin?

Here's the answer most "make a cloud drive on Linux" posts dodge. A rclone mount at ~/mnt/secret is a real path, so both file managers can browse it the moment you navigate there. What you usually want is the sidebar entry with an eject button — and that's where GNOME and KDE diverge.

GNOME's GVfs layer only auto-lists mounts it created itself, exposed under /run/user/<UID>/gvfs by the gvfsd-fuse daemon. A mount rclone made independently won't appear in Files' sidebar on its own. The clean fix is a systemd user unit that mounts on login, plus a .desktop bookmark (or a symlink into a watched location) so the path is always present and one click away. KDE's Dolphin is friendlier: kio-fuse mounts land under /run/user/<UID>/kio-fuse/ and Dolphin tracks them — but kio-fuse covers KIO protocols, not a third-party rclone mount, so you still bookmark the rclone path by hand.

For a mount that survives reboots and behaves like a permanent drive, a user-level systemd service beats a line in ~/.bashrc:

# ~/.config/systemd/user/rclone-secret.service  (ExecStart = the mount command above)
systemctl --user enable --now rclone-secret.service

Can't I just use WebDAV instead?

You can mount cloud storage over WebDAV with davfs2 or GVfs and get a drive-letter equivalent with almost no extra tooling. The catch is the one thing WebDAV quietly hides: WebDAV-over-HTTPS encrypts the transit, not the storage. The server terminates the TLS and writes your plaintext to disk. That defends against a network eavesdropper and does nothing against the provider itself, a subpoena, or a breached bucket. If your threat model is "I don't want the host able to read my files," WebDAV alone doesn't reach it — you'd layer rclone crypt underneath, at which point you're back to the FUSE mount above. WebDAV is a transport, not an encryption strategy. Don't let the convenience argue you out of client-side encryption.

Where beebeeb fits, stated plainly

beebeeb is end-to-end encrypted, zero-knowledge storage hosted in Falkenstein, Germany. Files are encrypted with AES-256-GCM under keys derived with Argon2id, and X25519 seals shares — all before anything leaves your machine. The server stores ciphertext and never holds a key. On Linux today, the live surface is the open-source bb CLI (plus the web app and WebDAV served through the CLI), so you can script uploads, sync directories, and pull files from a terminal right now. A native desktop client that mounts beebeeb as a first-class drive in your file manager — no rclone, no /etc/fuse.conf editing — is coming soon, not shipped. We won't pretend a drive app exists when it doesn't.

So, the honest recommendation. If you want an encrypted cloud mounted in Nautilus or Dolphin this afternoon, the rclone crypt plus FUSE stack above is the proven path over any backend, and it's worth learning whatever provider you land on. If you'd rather not own key backup, sharing, recovery codes, and the mount plumbing yourself, that's the gap a managed zero-knowledge client closes — see what's available now versus coming.