Neither one alone reproduces the Dropbox desktop client, and the honest answer is that you run both. An rclone mount with --vfs-cache-mode full gives you a folder that looks complete in your file manager, but every first read of an uncached file costs a network round trip, and nothing is available offline until you have opened it. rclone bisync gives you genuine local copies with local disk latency and true offline access, at the cost of a scheduled run, a mandatory first --resync, and conflict files you have to resolve yourself. Split your data: bisync the working set you edit daily, mount the archive you only read.
TL;DR by reader profile
-
Solo dev with one laptop and a home server, 40 GB of code and notes: run
bisyncon a 5 minute timer for the working set, because local disk latency and offline access matter more than seeing every remote change instantly. -
Photographer or media hoarder with 2 TB on object storage: run a single
mountwith--vfs-cache-mode fulland a capped cache, because copying 2 TB to every device defeats the point of moving off the hosted plan. -
Developer who builds inside the synced folder: never point a compiler, a
node_modulestree or a Git repository at a mount, because per file stat and open calls turn a 20 second build into minutes. -
Someone with two laptops and a phone editing the same files: bisync each laptop against the remote and expose the server folder over
rclone serve webdav, because bisync is two way between exactly two ends, not a mesh. -
Anyone on a metered or flaky connection: choose bisync with
--check-accessand a low--transfersvalue, because a mount reacts to a dropped link by returning I/O errors mid save. - Team of one who wants the sharing links back: accept that neither tool replaces them, and plan a second front end for public links rather than stretching rclone into the job.
The central tradeoff is simple: a mount buys you unlimited apparent capacity and pays for it in latency and fragility, while bisync buys you local speed and offline safety and pays for it in disk space, scheduling and conflict resolution.
Table of contents
- What does an rclone mount actually replace when the Dropbox client is gone?
- How does rclone bisync differ from a mount in day to day use?
- Which VFS cache mode should you run: off, minimal, writes or full?
- How much RAM and disk does an rclone mount really consume?
- What latency do open, stat and write calls show against a local disk baseline?
- How fast do remote changes appear, and what do dir-cache-time and poll-interval control?
- How do you size the VFS cache without filling the disk?
- Conflicts, renames and deletes: what bisync does and what the first resync costs
- What breaks when the network drops or the provider rate limits you?
- Running the mount under systemd and recovering it after a reboot
- Where should the mount run: home server, NAS, VPS or managed Personal Cloud Server?
- How do you reach the same folder from a phone or a second laptop?
What does an rclone mount actually replace when the Dropbox client is gone?
A mount replaces the appearance of the Dropbox folder, not its behaviour. rclone mount remote:files ~/Cloud --vfs-cache-mode full presents a FUSE filesystem where ls returns the full listing within milliseconds once the directory cache is warm, so your file manager, your editor's open dialog and find all behave normally. What changes is what happens underneath each file you touch.
Directory listings become remote metadata calls: the first ls on a cold directory hits the provider API, and rclone holds that listing for the --dir-cache-time window, which defaults to 5 minutes.
File contents arrive on demand: opening a 400 MB video streams it over the network rather than reading it from disk, and with --vfs-cache-mode full the bytes land in the cache directory only after that first read completes.
Writes go through a local staging file: in full or writes mode your application writes to the cache, the file closes, then rclone uploads it, so a save that returns instantly can still be in flight seconds later.
Offline access disappears by default: the Dropbox client kept every non selective file on disk, while a mount shows you names you cannot open when the link is down.
Selective sync has no equivalent: you approximate it with --exclude filters or a second mount, not with a checkbox.
The practical consequence is that a mount is excellent for an archive you read occasionally and poor for a directory you compile in. Treat it as a network drive with a good cache, which is what it is.
How does rclone bisync differ from a mount in day to day use?
Bisync is a scheduled job, not a filesystem. You run rclone bisync ~/Cloud remote:files from cron or a systemd timer, it compares both sides against a stored listing pair in ~/.cache/rclone/bisync/, and it copies the differences in both directions. Between runs, your local directory is an ordinary folder on an ordinary disk.
| Behaviour | rclone mount | rclone bisync |
|---|---|---|
| Where files live | Cache directory, populated on first read | Full local copy of everything in scope |
| Offline access | Only what is already cached | Every file, always readable and writable |
| Change propagation | Within the --dir-cache-time window, 5 minutes by default |
Only when the next scheduled run fires |
| Disk required | Whatever you cap the cache at | At least the size of the synced tree |
| Failure mode | I/O errors reaching the application mid operation | A run exits non zero and leaves both sides untouched |
| Conflicting edits | Last writer wins silently | Conflict files written to both sides |
The scheduling interval is the knob that defines the experience. A 5 minute timer means a file you save on the server appears on the laptop within 5 minutes and a deletion propagates on the same clock. A 60 minute timer halves your API calls and doubles the window in which the two sides can diverge.
The other practical difference is scope. A mount covers a whole remote cheaply because it stores almost nothing. Bisync covers only what you are prepared to store twice, which is why the working set versus archive split is the decision that shapes everything else.
Which VFS cache mode should you run: off, minimal, writes or full?
There are four modes and only two of them are realistic for a folder you actually work in.
--vfs-cache-mode off: files are read and written straight through, and any application that opens a file for both reading and writing fails, which rules out most editors, SQLite databases and Office formats.
--vfs-cache-mode minimal: files opened read write are staged on disk, everything else streams, so vim saves work but a seek backwards in a large file still costs a fresh range request.
--vfs-cache-mode writes: all writes go to the cache first and uploads happen on close, while reads stream from the remote every time, which suits a machine with a small disk and an append heavy workload such as a log or backup target.
--vfs-cache-mode full: reads and writes both use the cache, sparse chunks are kept, and a second open of the same file costs local disk latency instead of a round trip, which is the only mode that feels remotely like the old desktop client.
Run full unless the disk under the mount cannot spare the space. That disk is the real constraint, so decide where the mount lives before you tune the flags: a home server with a spare SSD, a NAS, a self managed VPS with a small volume, or a managed host. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user. Whichever you pick, budget cache space on the same box that runs rclone mount, because the cache is local by definition and cannot be pushed onto the remote.
How much RAM and disk does an rclone mount really consume?
Memory use is not a single number, it is a formula with three terms you control.
A base process footprint: a single mount process with nothing open is small enough that it is not the term you should worry about, and you can confirm yours with ps -o rss= -C rclone.
Read buffers, one per open file: --buffer-size defaults to 16 MiB and is allocated per file handle in use, so ten files open simultaneously is on the order of 160 MiB of buffers before anything else. Set --buffer-size 0 on a small box and accept more round trips.
Cached directory metadata: rclone keeps listings in memory for the --dir-cache-time window, and the cost scales with the number of objects you have walked, not their size, so a find across 500,000 files is what turns a quiet mount into a hungry one.
Upload concurrency: --transfers defaults to 4, and each in flight upload of a large file holds chunk buffers whose size depends on the backend, which is why a bulk copy into the mount is the peak you should size for.
Disk is simpler and more dangerous. With --vfs-cache-mode full the cache directory, by default under ~/.cache/rclone/vfs/, grows to hold every file you have read or written until an eviction rule removes it. Read one 40 GB video and you have written 40 GB locally. Two limits matter: --vfs-cache-max-size caps total bytes, and --vfs-cache-max-age defaults to 1 hour and expires idle entries. Leave both unset and the cache is bounded only by the filesystem it sits on.
What latency do open, stat and write calls show against a local disk baseline?
Measure your own numbers rather than trusting anyone's table, because the dominant term is the round trip time between your server and the provider region. Get the baseline first with ping to the endpoint host, then run strace -c -f ls -l in a cold directory on the mount and the same command in a bisync folder. The difference you see is the entire argument of this article.
Cold stat on a mount: costs at least one round trip if the parent directory is not cached, which is why a single ls -l on 2,000 files can take seconds while the same command on local disk returns in milliseconds.
Warm stat on a mount: served from kernel attribute cache and rclone memory, where --attr-timeout defaults to 1s and controls how long the kernel trusts what it was told.
First open and read: one round trip plus transfer time for the requested range, so latency scales with file size on a streaming read and with RTT on a small file.
Second open in full mode: local disk latency, because the bytes are already in the cache directory.
write followed by close: the write returns at local speed, then close blocks until the upload starts, so a save of a 2 MB file feels instant and a save of a 2 GB file does not.
Small files are where mounts lose decisively. A tree of 10,000 source files under 4 KB each turns into 10,000 metadata operations, and no cache mode fixes the first pass. A bisync folder pays that cost once per run, in the background, with --checkers running them in parallel.
How fast do remote changes appear, and what do dir-cache-time and poll-interval control?
Two independent timers decide when a file written elsewhere shows up in your mount, and confusing them is the most common reason people think the mount is broken.
--dir-cache-time, default 5m0s: the maximum age of a cached directory listing. When it expires, the next access re-lists that directory from the remote. Raise it to 1000h and you cut metadata calls to almost nothing, at the price of never noticing outside changes on your own.
--poll-interval, default 1m0s: how often rclone asks the backend for a change feed and invalidates only the affected directories. This is the mechanism that makes a long --dir-cache-time safe.
Backend support is the catch: polling depends on the backend implementing change notification. Google Drive, Dropbox and OneDrive do. Plain S3, Backblaze B2 and SFTP do not, and on those the only thing that refreshes a listing is --dir-cache-time expiry.
Manual invalidation as the escape hatch: start the mount with --rc and run rclone rc vfs/refresh recursive=true or rclone rc vfs/forget dir=path/to/folder to force a re-list immediately.
The practical recipe for a polling capable backend is --dir-cache-time 1000h --poll-interval 15s, which gives you near instant propagation and almost no idle API traffic. On a non polling backend such as B2, keep --dir-cache-time between 1m and 5m if you need freshness, and accept the listing calls, or leave it long and drive refreshes from whatever process writes the files.
None of this applies to bisync, where propagation is exactly your timer interval and nothing else.
How do you size the VFS cache without filling the disk?
Start from the largest single file you will ever write, not from your total data. The cache must hold a complete copy of any file being written, so --vfs-cache-max-size is a target for eviction, not a hard ceiling: an in use or not yet uploaded file is never evicted, and the directory can exceed the cap while an upload is in flight.
| Workload | Settings to start with | What you give up |
|---|---|---|
| Archive you mostly read, 500 GB SSD | --vfs-cache-max-size 100G --vfs-cache-max-age 720h |
100 GB of disk permanently committed |
| Small VPS with a 40 GB volume | --vfs-cache-max-size 8G --vfs-cache-max-age 24h |
Repeat reads of large files go back to the network |
| Write heavy target, backups or logs | --vfs-cache-mode writes --vfs-cache-max-age 1h |
Every read is a fresh download |
| Laptop with limited space | --vfs-cache-max-size 4G --vfs-cache-poll-interval 30s |
More frequent eviction churn on the disk |
| Large file editing, video or disk images | Cache at least 2x the biggest file | The cap is advisory during writes |
Eviction is least recently used and runs on --vfs-cache-poll-interval, which defaults to 1m0s. --vfs-cache-max-age defaults to 1h0m0s, so out of the box a file you read this morning is gone by lunchtime. Put the cache somewhere you control with --cache-dir /var/cache/rclone rather than leaving it under ~/.cache, and alert on that path at 85 percent full. Also watch --vfs-write-back, default 5s, which is how long a closed file waits before upload starts.
Conflicts, renames and deletes: what bisync does and what the first resync costs
The first run is not optional and it is not symmetric. rclone bisync ~/Cloud remote:files --resync establishes the baseline listings that every later run compares against, and by default path1 wins for files that differ on both sides. Run it on a copy first, or with --dry-run, because a careless --resync is the one command in this article that can overwrite good data.
Conflicts are renamed, not merged: when both sides changed since the last run, the default --conflict-resolve none keeps both and appends ..path1 and ..path2 to the filenames, leaving you to pick. Set --conflict-resolve newer if you would rather it decide, and --conflict-loser delete if you do not want the loser kept.
Deletes propagate, with a brake: --max-delete defaults to 50, meaning a run aborts if more than 50 percent of files on either side would be deleted, which is what saves you when a drive fails to mount.
Renames cost a full transfer: a renamed directory is seen as deletions plus new files, so moving a 20 GB folder re-uploads 20 GB.
A failed run leaves a marker: bisync writes its listings under ~/.cache/rclone/bisync/ and refuses to continue after an abort until you either fix the cause or re-run with --resync, which is deliberate.
Access checks catch empty mounts: --check-access requires an RCLONE_TEST file present on both sides and aborts if one is missing.
Budget the resync as a one time full comparison of both trees. On 40 GB it is minutes. On 2 TB it is the reason you chose a mount instead.
What breaks when the network drops or the provider rate limits you?
A mount fails loudly inside your applications. Bisync fails quietly in a log file. That difference matters more than any throughput number.
The mount returns I/O errors to whatever is reading: a dropped link mid read surfaces as EIO, and an editor that was saving may leave a partial file. If the FUSE process itself dies you get "transport endpoint is not connected" until you run fusermount -uz ~/Cloud and remount.
Pending uploads survive in the cache: with --vfs-cache-mode full, files closed but not yet uploaded stay in the cache directory and retry, so a reboot before the upload completes is the real risk, not a brief outage.
Retry behaviour is tunable: --low-level-retries defaults to 10 and --retries to 3, while --timeout defaults to 5m0s and --contimeout to 1m0s. Lower the timeouts on a flaky link so failures surface in seconds rather than minutes.
Rate limits show up as 403 and 429 responses: Google Drive enforces a 750 GB per day upload cap per account, and hitting it stops uploads for the rest of the day regardless of your flags. Use --tpslimit 10 to stay under per second quotas, and check rclone mount --stats 30s output or the log for pacer messages.
Bisync stops rather than guesses: a run that cannot reach one side aborts with a non zero exit code and no changes, which is safe but silent, so wire the timer to alert on failure with OnFailure= in the systemd unit.
Neither tool queues work indefinitely for you. A mount buffers only what fits in its cache, and bisync simply waits for its next scheduled attempt.
Running the mount under systemd and recovering it after a reboot
A mount started from a shell dies with the shell. Write a unit file, /etc/systemd/system/rclone-mount.service, and treat the mount as infrastructure.
Wait for the network, not just for boot: set After=network-online.target and Wants=network-online.target, because a mount that starts before DNS resolves fails immediately and leaves an empty directory that applications will happily write into.
Use Type=notify: rclone signals systemd once the mount is actually ready, so dependent services do not start against a directory that is not mounted yet.
Always set an ExecStop: ExecStop=/bin/fusermount -uz /home/you/Cloud handles the stale endpoint case on restart, and pair it with Restart=on-failure and RestartSec=10 so a crash recovers without you.
Decide who can see the mount: by default only the user running rclone can read it, and exposing it to Docker containers or other accounts needs --allow-other, which requires user_allow_other in /etc/fuse.conf.
Run bisync from a timer, not cron: a .timer with OnUnitInactiveSec=5min will not overlap runs the way cron can, and OnFailure= gives you a place to hang an alert.
If you run the mount as your login user rather than root, enable loginctl enable-linger $USER or the unit stops when you log out. Where this box lives is your call: a home server, a NAS, a self managed VPS, or a managed host. Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user. On any of them, verify recovery honestly by rebooting and then running findmnt /home/you/Cloud before you trust it with a working set.
Where should the mount run: home server, NAS, VPS or managed Personal Cloud Server?
Put the mount where the bandwidth and the cache disk are, then reach it from your laptop over the LAN or a tunnel. Mounting the same remote independently on four devices multiplies API calls and gives you four caches to keep warm.
| Location | Best for | Main constraint |
|---|---|---|
| Home server with a spare SSD | Large caches and 24/7 bisync timers | Your upload link caps every write to the remote |
| NAS appliance | Reusing disks you already own | Vendor kernels may not load fuse, and package availability is limited |
| Self managed VPS | Fast symmetric bandwidth near the provider region | Small volumes force a low --vfs-cache-max-size, and egress may be billed |
| Managed Personal Cloud Server | One click app installs and public HTTPS without port forwarding | You work within the app store and container model |
| The laptop itself | A single device setup with no server | Cache and mount vanish when the lid closes |
Yundera is a managed Personal Cloud Server, built on CasaOS, that runs self-hosted apps as Docker containers on a server dedicated to the user, with each app reachable on a public HTTPS subdomain through NSL.SH mesh routing.
Two details decide more than the category. First, if rclone runs inside a container, a FUSE mount needs --device /dev/fuse and --cap-add SYS_ADMIN, and the mount is visible only inside that container unless you add --allow-other and a shared bind mount. Second, colocation matters: a VPS in the same region as your bucket turns a 100 ms round trip into single digit milliseconds, which is the single largest latency win available to you.
How do you reach the same folder from a phone or a second laptop?
Do not mount the remote a second time. Re-export the copy you already have on the server, and serve the bisync folder rather than the mount so you are not stacking one cache on top of another.
rclone serve webdav /srv/cloud --addr :8080 --user you --pass secret: the broadest client support, readable by Finder, Windows Explorer, and mobile apps on both platforms, at the cost of chatty per file requests over a slow link.
rclone serve sftp: better for large files and lossy connections, and it gives you an existing client on every laptop through sshfs or an SFTP capable file manager.
rclone serve s3: useful when the consumer is a backup tool or a script that already speaks the S3 API rather than a human with a file browser.
Samba on the same directory: the right answer when the second laptop is on the same LAN and you want native Finder or Explorer behaviour including proper file locking.
A second bisync pair on the other laptop: the only option that gives that machine genuine offline copies, and the reason to remember that bisync links exactly two endpoints, so three devices means each syncs to the remote, not to each other.
Two rules keep this safe. Never expose rclone serve directly to the internet on a plain HTTP port: put it behind a reverse proxy with TLS, or reach it over a WireGuard or Tailscale tunnel so the listener stays on a private interface. And pick one writer per file where you can, because WebDAV clients and bisync runs editing the same path within the same 5 minute window is exactly how you manufacture conflict files.
Top comments (2)
the failure-mode split is the bit i'd emphasize. for bisync, i'd make the timer alert on a nonzero exit and keep an append-only log of resyncs and deletes. for a mount, alert on cache fullness and verify the mountpoint is real before apps start. that catches the scary silent cases.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.