rclone mount vs rclone bisync after Dropbox: the real latency, RAM and conflict numbers

Description and use

Users can replace Dropbox by combining rclone bisync for daily edits (offline, low latency) and rclone mount for large archives (unlimited apparent capacity).

Problem

Users need to replace Dropbox’s desktop client with rclone while balancing latency, offline access, and disk usage.

Outcome

Users can achieve a Dropbox‑like experience by combining rclone bisync for daily edits (offline, low latency) and rclone mount for large archives (unlimited apparent capacity).

Workflow

• 1. Decide which data set is "working set" (daily edited files) and which is "archive" (read‑only).
• 2. For the working set, schedule rclone bisync (e.g., every 5 min) with --resync on first run and resolve conflicts manually.
• 3. For the archive, run rclone mount remote:files ~/Cloud --vfs-cache-mode full (optionally cap cache with --vfs-cache-max-size).
• 4. If multiple devices need access, expose the server folder via rclone serve webdav or sync each device with bisync.
• 5. Monitor cache size and network usage; adjust --dir-cache-time, --transfers, and --check-access for metered or flaky connections.

Evidence

Neither one alone reproduces the Dropbox desktop client, and the honest answer is that you run both.

Source

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.

Source

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.

Source

Split your data: bisync the working set you edit daily, mount the archive you only read.

Source