Credit first
rclone is one of the best pieces of infrastructure software of the past decade. Free, scriptable, and it speaks more backends than anything else. If rclone mount already runs on your machine and you never think about it, keep it. We are not here to argue you out of a tool that works.
This page is for the other case: you ran rclone mount, hit the driver layer or the cache flags, and went looking for something with a window instead of a man page.
The friction sits below rclone, not inside it
rclone's own mount documentation states the requirements plainly. They are not rclone's fault. They are the price of pretending a remote bucket is a POSIX filesystem.
- macOS needs a FUSE implementation. macFUSE is still, in 2026, a kernel extension, so on Apple Silicon you boot into recovery, drop the security policy to Reduced Security, approve the extension, and reboot again. A major macOS upgrade can send you back through parts of it.
- Windows needs WinFsp installed before rclone mount does anything at all. Another driver, another elevation prompt, another component to keep current.
- Linux is the easy path. That is why Linux users rarely write blog posts like this one.
Then there is the cache decision. rclone's own docs are blunt about it: with the default mode a file cannot be open for reading and writing at once, and plenty of ordinary applications misbehave against the mount unless you pick writes or full. So you choose a mode, a cache directory, a size limit, a max age. The mount now has a tuning surface.
Autostart is its own small project: a launchd plist on macOS, a systemd user unit on Linux, a Task Scheduler entry on Windows. And all of it comes after rclone.conf, where the Google Drive section steers you toward registering your own OAuth client ID in Google Cloud Console because the shared one is rate limited. Sound engineering. Also an afternoon you do not get back.
The workaround the community already settled on
Scroll far enough into any rclone forum thread about FUSE pain and someone suggests the same thing: forget mount, run rclone serve webdav, then map that URL as a network drive. It works. Every desktop OS has shipped a WebDAV client for twenty years, and none of them need a kernel driver.
That pattern is exactly what AnyStorage packages as an app.
An rclone mount alternative that is just an app
You add storage through a GUI: 20 connection types, including S3, Cloudflare R2, Backblaze B2, Google Cloud Storage, Google Drive, OneDrive, Dropbox, SFTP, FTP, another WebDAV server, and plain local folders. OAuth happens in the app, and there is no config file to hand-edit.
Then open Services in the sidebar, switch to the WebDAV tab, and press Start. One endpoint appears: http://127.0.0.1:3211 by default, port configurable from 1 to 65535. HTTP Basic authentication is always on, with the username defaulting to anystorage and a 24-character generated password. Both are editable, there is a Regenerate button, and copy buttons for all three fields.
Each connection currently connected in the app becomes a folder at the WebDAV root, named after the connection. Mounting uses the tools your OS already has. On macOS that is Finder, Go, Connect to Server, Cmd+K, paste the URL, connect as a registered user. On Windows it is File Explorer, This PC, Map network drive. Any third-party WebDAV client works too, and on Windows we would suggest one.
Reads stream with HTTP range support, so seeking into the middle of a video does not download the whole file first. Writes stream too. Leave the server toggle on and it comes back up with the app next launch, which is the closest thing here to autostart config.
No kernel extension. No WinFsp. No reduced-security boot. No admin rights. Nothing to reinstall after an OS upgrade.
The limits, up front
- The free tier serves WebDAV read-only. Read-write is a Pro feature, and you can also pin it to read-only on Pro on purpose.
- There is no TLS. The URL is plain http, which is why we bind 127.0.0.1 by default. The optional LAN mode binds 0.0.0.0 and the app warns you, because Basic credentials would then cross the network in the clear.
- There is no real locking, so two machines editing the same file are not protected from each other. Do not treat this as collaboration infrastructure.
- Connections connect lazily. After you restart the app, a connection appears under the WebDAV root only once you have opened it in the app. Newly created connections show up without restarting the server.
- Top-level connection folders cannot be renamed or deleted over WebDAV, and you cannot copy a file directly between two connections through the mount. Route it through local disk, or use the app's transfer UI.
- Windows' native WebDAV client carries its own history: the WebClient service is deprecated and often not running, HTTP Basic is refused until BasicAuthLevel is set to 2 under HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters, and FileSizeLimitInBytes defaults to 50,000,000 bytes, so anything larger fails with 0x800700DF. A third-party client, or the app itself for big transfers, avoids all of it.
Where rclone still wins
Scheduled sync and bisync with filters. crypt, union, chunker. dedupe and check. Headless servers with no desktop at all. Anything you want to express as a cron line. AnyStorage does not replace that, and we would not pretend otherwise.
Plenty of people run both: rclone for the jobs that belong in a script, and a local WebDAV endpoint for the moments when a file needs to be visible in Finder or Explorer right now.