The fast answer, and the wall you hit
You can mount cloud storage as a Finder drive today with rclone. On Apple Silicon the classic route runs into macFUSE, which is still a kernel extension: loading it means booting into Recovery and dropping your Mac to Reduced Security. The clean way around it in 2026 is FUSE-T, or, on macOS 26 Tahoe, the FSKit backend, which needs no kext at all. The rest of this is the procedure, the tradeoffs, and where beebeeb fits, which is not "install our drive app" because that app isn't out yet.
Why is macFUSE the part that bites on Apple Silicon?
rclone doesn't mount anything by itself. It hands a virtual filesystem to a FUSE driver, and on macOS the historical default is macFUSE, which is still a kernel extension. Apple has been deprecating kexts for years, and on M-series Macs they don't load quietly.
To run macFUSE on Apple Silicon you have to:
- Shut down and boot into Recovery (hold the power button until "Loading startup options" appears).
- Open Startup Security Utility and set the policy to Reduced Security.
- Tick "Allow user management of kernel extensions from identified developers."
- Reboot, approve macFUSE under System Settings → Privacy & Security, then reboot again.
The macFUSE author argues Reduced Security is misleading branding, that it leaves you roughly where macOS sat a few releases ago. Fair point. But it's still a system-wide downgrade to mount a cloud drive, and on a managed or work Mac it may be blocked outright. Mounting an encrypted volume in Finder shouldn't cost you a security policy. For a long time, it did.
The kext-less path: FUSE-T, and FSKit on macOS 26
FUSE-T is a FUSE implementation that never touches the kernel. Instead of a kext it spins up a small local NFSv4 server and lets macOS mount that over loopback. No Recovery boot, no Reduced Security, no reboot. Install it, run rclone mount, and rclone auto-detects FUSE-T when macFUSE isn't present. The volume appears in Finder like any other.
macOS 26 Tahoe shipped on 15 September 2025 with FSKit, a supported way to implement filesystems in user space. Both FUSE-T and macFUSE 5.1+ now run through FSKit, so the loopback-NFS workaround disappears and the kext goes with it. On Tahoe this is the cleanest option going: a real user-space filesystem with Apple's blessing and zero security toggles.
The honest caveat: FSKit support is new, and a loopback NFS server (FUSE-T's older mode) behaves a little differently from a kernel filesystem. Some Spotlight-heavy or backup tools that poke at filesystem internals still prefer macFUSE. For everyday Finder use — copy, rename, open in an app — FUSE-T is fine and far less invasive.
Mounting a remote in Finder with rclone, step by step
This works for any rclone-supported remote, including a WebDAV endpoint. The flag that matters for WebDAV is --vfs-cache-mode writes: WebDAV can't stream writes, and most Mac apps expect random-access files. On an NFS-backed mount without it, your mount point comes up read-only.
- Install the pieces:
brew install rclone, then grab FUSE-T from its releases page (or macFUSE, if you've accepted the kext tradeoff). - Configure the remote:
rclone config, pick the backend, store the connection. rclone keeps credentials in~/.config/rclone/rclone.conf. - Make a mount point:
mkdir -p ~/CloudDrive. - Mount:
rclone mount myremote: ~/CloudDrive --vfs-cache-mode writes --volname "Cloud"
The volume lands in Finder's sidebar. To survive a reboot, wrap that command in a launchd agent under ~/Library/LaunchAgents rather than leaving a Terminal window open. Keep --no-unicode-normalization=false (the default) — macOS is fussy about filename normalization.
One thing to keep straight: a WebDAV mount over HTTPS encrypts the transit, not the storage. If the server on the other end can read your files, mounting them in Finder doesn't make them private — it makes them convenient. The encryption has to happen on your machine, before the bytes leave, for the provider to be unable to read them. "Encrypted" on the wire and "encrypted" against the host are different promises.
Where beebeeb actually sits today
beebeeb is zero-knowledge: files are encrypted on your device with AES-256-GCM, keys derived with Argon2id, and the server in Falkenstein, Germany only ever stores ciphertext. That sharpens the Finder question: how do you get locally-decrypted files into Finder without ever handing the server a readable copy?
Two answers are live right now, both through the open-source bb command-line client. A third is on the way.
| Path | How it works | Needs macFUSE? | Status |
|---|---|---|---|
bb webdav | Local WebDAV server on 127.0.0.1:7878 that decrypts on the fly; connect Finder to http://localhost:7878 | No | Live |
bb mount <point> | Mounts the vault as a FUSE filesystem, decrypting on read | Yes (libfuse3 on Linux) | Live |
| Native Finder app | A no-CLI drive that lives in the sidebar | No | Coming soon |
bb webdav is the route most people want, and it sidesteps the macFUSE problem entirely. You run it, it serves your decrypted vault over a loopback HTTP server bound to 127.0.0.1, and you connect Finder with Go → Connect to Server → http://localhost:7878. Decryption happens inside the bb process on your laptop. The server in Germany was never in the loop — it handed over encrypted chunks and your machine turned them into files. No kext, no Reduced Security, no reboot. It runs locally, so it's quick, and it shows up as a mounted share.
If you want a real filesystem mount with inode semantics rather than a network share, bb mount ~/Beebeeb gives you that through FUSE — which drops you back into the macFUSE-or-FUSE-T decision above. Same crypto, same local-decrypt guarantee, different plumbing.
What we don't have yet, and won't pretend to, is a native macOS app that mounts your vault as a Finder drive with zero terminal. That's a planned roadmap item, built on the File Provider extension so it behaves the way iCloud Drive does: on-demand download, offline pinning, no kext. Until it ships, bb webdav is the honest, working answer, and it's a good one.
Which mount path should you pick?
On macOS 26 Tahoe, use FSKit through FUSE-T or macFUSE 5.1+ and skip the kernel-extension era entirely. On an older Apple Silicon Mac where you won't touch the security policy, FUSE-T is your path. If you specifically need a tool that misbehaves on NFS-backed mounts, macFUSE with Reduced Security is the fallback, eyes open about the cost.
And if the real goal is a cloud the provider genuinely can't read, the mount technology is the easy half. The hard half is that the files have to be ciphertext before they leave your machine — which rules out plain WebDAV against a host that holds your keys.