rclone mount FUSE Errors: Linux, macOS, Windows

Four errors, one requirement

rclone mount is not really an rclone feature. It is a filesystem driver feature that rclone drives, and every error below is the driver layer refusing to cooperate. Here are the four you will actually meet, quoted as they were reported.

Fatal error: failed to mount FUSE fs: fusermount: exec: "fusermount3": executable file not found in $PATH

panic: cgofuse: cannot find winfsp

Cannot create WinFsp-FUSE file system: mount point in use.
Fatal error: failed to mount FUSE fs: mount stopped before calling Init: mount failed

NOTICE: mount helper error: fusermount3: mount failed: Permission denied
CRITICAL: Fatal error: failed to mount FUSE fs: fusermount: exit status 1

Linux: the tools, then AppArmor

The first error is exactly what it says. rclone shells out to the FUSE mount helper, and on a FUSE 3 system that binary is fusermount3. If the package is missing — common on minimal containers and on appliance distributions — nothing else in rclone matters.

which fusermount fusermount3
sudo apt install fuse3        # Debian, Ubuntu
sudo dnf install fuse3        # Fedora, RHEL

The second Linux error is newer and stranger, and rclone's own mount documentation calls it out: "On newer versions of Ubuntu, you may encounter the following error when running rclone mount", followed by the mount helper error: fusermount3: mount failed: Permission denied text above. The documented cause is AppArmor: "This may be due to newer Apparmor restrictions, which can be disabled with sudo aa-disable /usr/bin/fusermount3 (you may need to sudo apt install apparmor-utils beforehand)."

Unmounting uses the same helper, which is worth knowing because a half-dead mount point produces confusing errors the next time:

fusermount -u /path/to/local/mount
fusermount3 -u /path/to/local/mount

Windows: WinFsp is not optional

rclone's documentation is unambiguous: "To run rclone mount on Windows, you will need to download and install WinFsp. WinFsp is an open-source Windows File System Proxy which makes it easy to write user space file systems for Windows. It provides a FUSE emulation layer which rclone uses in combination with cgofuse."

Without it you get the panic: cgofuse: cannot find winfsp stack trace — a panic rather than a polite message, because the FUSE layer cannot even initialise. WinFsp describes itself as "system software that provides runtime and development support for custom file systems on Windows computers", similar to FUSE on UNIX-like systems. Install it, reboot if prompted, and retry.

The second Windows error is a different animal. Cannot create WinFsp-FUSE file system: mount point in use. usually means the folder you pointed at already exists. The user who reported that message solved it themselves in two minutes: "All I have to do is make sure that the mount folder does not exist. I already created the folder hence the error." A drive letter that is genuinely free works too:

rclone mount remote: X: --vfs-cache-mode writes
rclone mount remote: C:\path\parent\mount --vfs-cache-mode writes

macOS: two drivers, one choice

On macOS, rclone documents three options and describes the trade-off precisely: "Mounting on macOS can be done either via built-in NFS server, macFUSE (also known as osxfuse) or FUSE-T. macFUSE is a traditional FUSE driver utilizing a macOS kernel extension (kext). FUSE-T is an alternative FUSE system which 'mounts' via an NFSv4 local server."

That sentence is the whole decision. macFUSE means a kernel extension, which on current macOS means approving it in system settings and, usually, a reboot. FUSE-T avoids that: its own project page describes a "Kext-less design with no kernel extension required", mounting through a local server instead, with NFS, SMB and native FSKit backends.

Neither is free of edge cases, and rclone lists them. With FUSE-T, per the project wiki, "File access and modification times cannot be set separately as it seems to be an issue with the NFS client which always modifies both" — which means Finder browsing a mount can update modification times and provoke rclone into re-uploading whole files. And with --read-only under FUSE-T, writes "fail silently as opposed to with a clear warning as in macFUSE".

If you installed macFUSE through MacPorts rather than the dmg, rclone documents the extra step required before its libraries are found:

sudo mkdir /usr/local/lib
cd /usr/local/lib
sudo ln -s /opt/local/lib/libfuse.2.dylib

When the mount exists but behaves badly

Once the driver is in place, most remaining complaints are the VFS cache. rclone documents four modes, and the difference is not subtle. --vfs-cache-mode off will "read directly from the remote and write directly to the remote without caching anything on disk". minimal is "very similar to 'off' except that files opened for read AND write will be buffered to disk". With writes, "files opened for read only are still read directly from the remote, write only and read/write files are buffered to disk first". With full, "all reads and writes are buffered to and from disk".

Applications that open a file for read-write, seek backwards, or rename in place — which is most desktop software — need at least writes. Reaching for full fixes the rest at the cost of disk.

The design that removes the driver entirely

Every error on this page comes from the same architectural choice: a filesystem driver in the kernel. There is another way to get a drive, and it predates FUSE on every one of these platforms — WebDAV, which all three operating systems already mount without installing anything.

That is how AnyStorage (v0.2.24; macOS 11+, Windows 10+, Ubuntu 20.04+) works. It runs a built-in WebDAV server on http://127.0.0.1:3211, and every storage connection open in the app — S3-compatible endpoints with path-style addressing and a custom region, Cloudflare R2, MinIO, Backblaze B2, SFTP with key authentication, WebDAV — appears as a folder under that root. No FUSE, no WinFsp, no macFUSE, no kernel extension to approve, no fusermount3 in $PATH. The free tier allows two connections.

The honest caveat: the OS WebDAV clients have their own limits, and on Windows the redirector has a documented 50,000,000-byte default file size cap in the 50 MB limit page. That is a registry value, not a driver install, which is the whole point of the comparison.

Next steps

• A desktop alternative to the mount command: rclone mount alternative
• One drive for every backend: mount cloud storage as a local drive
• If the WebDAV route fails on Windows: WebDAV error 0x80070043