A 2 TB bucket does not fit on a 512 GB laptop. That one sentence is why "sync" and "mount" get used interchangeably in marketing copy while behaving like two completely different deals in practice.
Sync copies, mount streams
A sync client keeps a full local copy of a remote folder. Every file lands on disk, reads are instant, offline works, and your SSD fills up. Fine, until the far side is a media archive or a bucket that was never meant to fit on a laptop.
A mount does the opposite. The file manager asks for a directory listing and gets one; the bytes of a file move only when something opens it. A 2 TB bucket shows up in Finder or File Explorer without spending 2 TB of SSD. The price is that with no network you have a folder full of names and nothing behind them.
Vendor sync clients have blurred this line for years with on-demand placeholder files, and they do it well. For their own folder, on their own platforms.
Sync is still the right call sometimes
Being straight about this matters more than winning the argument.
- You work offline often. Flights, trains, conference wifi. Placeholders are useless there.
- The files are a working set, not an archive. A 4 GB project folder you touch daily belongs on local disk.
- Something is going to walk the whole tree. Git repositories, photo libraries and IDE indexers fire thousands of tiny metadata calls, and over any network mount they crawl.
- Your editor does atomic saves. Write-to-temp-then-rename is free locally and tedious over a remote file system.
Mounting wins on the other side of the ledger: media libraries, design assets, build artifacts, backup targets, log archives, anything you look at far more often than you edit.
Three usual routes to a mounted drive
Vendor clients with a streaming mode
Dropbox, OneDrive and Google Drive for Desktop all offer some flavour of keep this online only, and they are decent software. But it is one client per provider, each with its own updater and its own mount root. Google's has no Linux build, and object storage like S3, R2, B2 or MinIO has no first-party desktop client at all.
FUSE-based drivers
The classic power-user route: macFUSE with rclone mount, sshfs, s3fs. A real file system, paid for with a kernel extension. On Apple Silicon that means enabling reduced security from Recovery and rebooting more than once, then hoping the next macOS upgrade does not break it. On Windows it means the WinFsp driver and admin rights. Then come cache-mode decisions, a launchd or systemd unit so the mount survives a reboot, and a config file to maintain.
Protocols the OS already speaks
Every desktop OS ships a client for SMB, FTP and WebDAV. No driver, no admin prompt, nothing to reinstall after a system update. The historical catch is that your cloud provider speaks none of them, so you put something local in between.
Mount cloud storage as a local drive through one local endpoint
That in-between piece is what the WebDAV server built into AnyStorage does. Sidebar, Services, WebDAV tab, Start. You get http://127.0.0.1:3211 by default, the port configurable anywhere from 1 to 65535, and HTTP Basic authentication always on: username anystorage, a 24-character password generated on first use, both editable, a Regenerate button, copy buttons for all three. Leave it enabled and the server comes back with the app next launch.
Every storage connection currently connected in the app appears as a folder at the root of that endpoint, named after the connection. An S3 bucket, a Cloudflare R2 bucket, Google Drive, Dropbox, a Seafile server, an SFTP box, a local folder. Twenty connection types, side by side in one mount instead of one mount each.
Then you mount it with the tools already on the machine. On macOS: Finder, Go menu, Connect to Server, or Cmd+K, paste the URL, connect as a registered user with the credentials from the app. On Windows: File Explorer, This PC, Map network drive, same URL. Any third-party WebDAV client works too. There is no auto-mount button in the app; it hands you the URL and a copy button, and the operating system does the mounting.
Reads use HTTP range requests, so you can drag the scrubber into the middle of a 6 GB video and it plays from there instead of fetching 6 GB first. Writes stream as well, with no whole-file buffering in memory.
No kernel extension. No macFUSE, no WinFsp, no admin rights, no reduced-security boot, no config file, no cache-mode flag to guess at. Same behaviour on macOS, Windows and Linux, and a macOS upgrade does not take it out.
What it does not do
- The free tier runs the WebDAV server read-only. Read-write is a Pro feature, and Pro users can still pin it to read-only on purpose.
- There is no TLS in the current version. The URL is plain http, so keep it on 127.0.0.1. The optional LAN mode binds 0.0.0.0 and the app warns you, because Basic credentials would then cross the network in plaintext.
- After you restart the app, a connection shows up under the WebDAV root only once you have opened it in the app. Connections connect lazily. New connections appear without restarting the server.
- There is no real file locking, so two machines editing the same file are not protected from each other. A convenience mount, not collaboration infrastructure.
- Through the mount you cannot delete or rename the top-level connection folders, and you cannot move or copy files directly between two connections. Copy down, then copy up, or do it in the app.
- Windows' native WebDAV client has history. The WebClient service is deprecated as of 2026 and often not running, Basic auth over http is refused until BasicAuthLevel is raised under HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters, and FileSizeLimitInBytes defaults to 50,000,000 bytes, failing larger copies with 0x800700DF. A third-party WebDAV client, or the app itself for big transfers, sidesteps all of it.
Mounting is not a replacement for syncing. It answers a different question: can I open these files from an ordinary application right now, without paying for them in disk space? For a bucket, an archive or a media library the answer should be yes, and getting there should not involve a kernel extension.