DEV Community

John
John

Posted on

RClone vs Dropbox and Google Drive Sync: Does Client-Side Crypt Give You Private Cloud Storage?

#opensource #privacy #selfhosted

Yes, an rclone crypt remote keeps the provider from reading your file contents and, if you enable filename encryption, your file names too. It does not hide your directory structure, your approximate file sizes, your access times or the fact that you are storing data at all. Crypt is a strong answer to "can Dropbox read my documents" and a weak answer to "can Dropbox profile my behaviour". Treat it as an encryption layer bolted onto a service you still do not control, not as a replacement for controlling where the bytes live.

TL;DR by reader profile:

  • Leaving a paid Dropbox plan for privacy reasons, like a freelance designer with 400 GB of client work: wrap your existing provider in a crypt remote first, then decide about moving hosts later, because encryption is the part that actually changes the provider's access.
  • Wanting the sync experience back, like a household sharing photos across three laptops: crypt plus rclone breaks the native desktop client, so budget for rclone bisync or mount and accept manual conflict handling.
  • Storing backups rather than working files, like a homelab owner pushing nightly Restic or Borg snapshots: skip crypt entirely, because Restic and Borg already encrypt client side and a second layer just costs CPU.
  • Handling regulated or client-confidential data, like a small accountancy practice under GDPR: crypt gives you a defensible encryption story, but the metadata leakage and key custody questions need answering in writing before you rely on it.
  • Running a home server or NAS already, like a Synology owner with 8 TB of disks: use crypt to encrypt an offsite copy, and keep the authoritative copy on hardware you own.
  • Dealing with millions of small files, like a developer syncing node_modules or a photo library with sidecars: measure first, because the per-file overhead and lost server-side deduplication hit small files hardest.

The central tradeoff: crypt buys you confidentiality against the provider at the cost of native sync clients, server-side deduplication, delta transfers, search, previews and web access, and it never buys you anonymity.

Table of contents

What does rclone crypt actually encrypt, and what does it leave in plain sight?

Crypt is a wrapper remote. You point it at a path on an existing remote, and every file written through it is encrypted on your machine before a single byte reaches Dropbox or Google Drive. File contents use XSalsa20-Poly1305 in 64 KiB chunks, with a 32 byte header holding a random nonce at the start of each object. The provider stores opaque blobs.

What survives the wrapper is more than most people expect.

  • Directory structure: crypt encrypts each path component separately, so a 4 level deep tree on your disk is still a 4 level deep tree in the provider's storage, with the same branching shape.
  • File sizes: an encrypted object is a deterministic function of the plaintext size, 32 bytes of header plus 16 bytes of overhead per 64 KiB chunk, so sizes are recoverable to within a few tens of bytes.
  • Timestamps and access patterns: modification times are stored as provider metadata in the clear, and the provider logs every read, write and delete with its own timestamps.
  • File counts and total volume: the number of objects and how they grow over time is fully visible, which is often enough to infer what kind of data you keep.
  • Filenames, unless you ask: filename_encryption = off leaves names readable, and only standard or obfuscate change that.

Run rclone config show secret: after setup and check the filename_encryption and directory_name_encryption values yourself. The defaults in an interactive rclone config session are standard and true, but a copied config or a scripted setup can quietly leave both disabled.

How does crypt compare to Dropbox and Google Drive server-side encryption?

Both providers encrypt at rest and in transit. The difference is not the algorithm, it is who holds the key.

Property Provider server-side encryption rclone crypt
Key custody Held by Dropbox or Google, rotated without your involvement Derived from your password and salt in rclone.conf
Protects against Stolen disks, a datacentre breach, an unencrypted backup tape The provider itself, a subpoena served on the provider, an account takeover
Provider-side features Web preview, full text search, sharing links, Google Docs conversion None, the provider sees only blobs
Access by staff or automated scanning Possible in principle, both run content scanning for abuse and malware Not possible without your password
What a legal request yields Readable files and metadata Ciphertext and metadata only

Server-side encryption answers a threat model that mostly protects the provider, not you. Google Workspace offers client-side encryption on Enterprise Plus tiers, but the key service is still something you configure inside Google's ecosystem. Crypt moves the boundary to your own machine, which is exactly why the web interface stops being useful.

That boundary has a physical location. The key material sits in rclone.conf on whatever device runs the sync, so the security of the whole arrangement reduces to the security of that machine. It might be a laptop, a 5 euro VPS, a NAS, or a Personal Cloud Server. 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, that box is now the single point that can read your data.

Is client-side encryption enough to stop a provider reading your files?

For file contents, yes. Nobody at Dropbox or Google can turn an rclone crypt blob into a readable document without your password. The honest answer is that "reading your files" is a narrower win than "being private", and the gap is where most people get surprised.

  • Your identity is still attached: the account is in your name, paid with your card, accessed from your home IP, and the provider retains connection logs regardless of what the objects contain.
  • Confidentiality is not availability: encryption does not stop an account suspension, a quota enforcement action or a deletion. If the provider locks the account, you have unreadable data you also cannot download.
  • The key derivation is only as good as the password: crypt runs scrypt over your password and salt. A short passphrase is brute-forceable offline once someone holds the ciphertext, and they hold it permanently.
  • rclone.conf is the real target: an attacker with that file and the config password, or with none if you never set one, has everything. Storing it in a dotfiles repo has ended more setups than any cryptographic weakness.
  • Nothing stops traffic analysis: the provider sees a 4 GB upload at 02:00 every night and a burst of reads whenever you open a project. That pattern is informative on its own.

Compare that to Proton Drive or Tresorit, where the encryption is native and the client keeps working. You trade rclone's flexibility for an integrated product. Compare it to self-hosted storage, where the identity and the logs never leave your own machine in the first place.

How do you set up a crypt remote over Dropbox or Google Drive step by step?

Crypt never talks to a provider directly. You build the provider remote first, then wrap it. Expect two entries in rclone.conf for every one encrypted destination.

  1. Create the base remote: run rclone config, choose dropbox or drive, and name it something you will recognise later, for example gdrive. For Google Drive, register your own OAuth client ID in Google Cloud Console rather than using rclone's built in one, which is shared by every user of the tool and throttled accordingly.
  2. Authorise it, headless if needed: on a machine with no browser, run rclone authorize "drive" on your laptop and paste the returned token into the config prompt. This is the normal path for a VPS or a NAS.
  3. Create a container folder: make one directory that will hold nothing but ciphertext, such as gdrive:encrypted. Mixing plaintext and crypt data in the same path makes later auditing painful.
  4. Add the crypt remote: choose crypt, set remote = gdrive:encrypted, accept standard for filename encryption, and answer true for directory name encryption unless you have a specific reason not to.
  5. Generate the password and salt: let rclone generate both at 128 bits rather than typing a passphrase. Write them down offline before you continue, because the config file stores them obscured, not recoverable in your head.
  6. Verify before trusting it: rclone copy ./testdir secret:testdir, then rclone ls gdrive:encrypted to confirm you see gibberish, then rclone check ./testdir secret:testdir to confirm round trips match.

Only after step 6 should you point anything real at it.

What do the three filename encryption modes cost you in path length and compatibility?

filename_encryption has three values, and the default is not the only sensible choice.

  • standard: names are encrypted with AES in EME mode and encoded, which inflates them. Rclone's own documentation puts the safe threshold at file names under 156 characters, above which you risk breaching provider path limits. Deeply nested project trees with long descriptive names are the usual casualty.
  • obfuscate: a simple rotating substitution keyed to your password. It defeats casual browsing but not analysis, and it is not real encryption. Its advantage is that name length barely changes, so path limits stop being a problem.
  • off: names are stored exactly as they are on disk. You get full compatibility and zero inflation, and the provider gets a complete inventory of what you own. 2024-tax-return-final.pdf tells a reader almost everything before they fail to decrypt it.
  • directory_name_encryption: an independent switch. Set it to false with standard file names if you need readable folders for your own navigation and accept that folder names leak.
  • filename_encoding: controls the alphabet used. The default base32 is the most portable. base32768 packs more information per character and allows noticeably longer names, but only where the provider handles the wider character set cleanly.

Switching modes later is not a config edit. Rclone cannot recognise files written under a different scheme, so you must create a second crypt remote and run rclone move oldsecret: newsecret:, which means re-uploading every byte. Decide before the first large upload, not after 300 GB.

How much storage and speed overhead does crypt add per file?

The storage cost is deterministic: a 32 byte header, plus 16 bytes of authentication tag for every 64 KiB chunk. That makes it negligible for media and painful for tiny files.

Plaintext size Stored size Overhead
100 bytes 148 bytes 48%
1 KiB 1,072 bytes 4.7%
1 MiB 1,048,864 bytes 0.027%
1 GiB 1,074,003,984 bytes 0.024%

A 50,000 file source tree of small text files pays a visible tax. A 400 GB video archive pays almost nothing. Run rclone size ./source against rclone size secret: after your first sync to see your own ratio rather than guessing from this table.

Speed is a different story. XSalsa20-Poly1305 is a stream cipher chosen for software performance, and on any x86-64 machine from the last decade the cipher is not your bottleneck: the upload link is. On a Raspberry Pi 4 or a low-power ARM NAS, encryption can become the limit on a fast fibre connection, so test before assuming.

The real slowdown is per-object, not per-byte. Crypt adds a name encryption step per path component, and rclone must buffer and transform each file rather than streaming it untouched. With --transfers 4 and thousands of small files, the per-file cost dominates. Raising --transfers and --checkers helps until the provider starts returning rate limit errors, which Google Drive does aggressively on per-file operations. Large files, few of them, is the shape crypt handles best.

Why does crypt break deduplication, delta sync and versioning on your provider?

Every file gets a fresh random 24 byte nonce. Encrypt the same 200 MB video twice and you produce two completely different objects. That single design decision, which is correct cryptographically, removes most of what makes a commercial sync service efficient.

  • Cross-file and cross-account deduplication stops: providers save space by storing one copy of a block that millions of accounts hold. Your ciphertext matches nothing, so you are billed for every byte you upload, including the copies you did not realise you had.
  • Block-level delta sync stops: the Dropbox desktop client uploads only the changed portion of a file. Rclone through crypt has no equivalent. Change one comment in a 400 MB Photoshop file and you re-upload 400 MB, every time.
  • Provider-side hash verification stops: rclone cannot compare a local MD5 against the stored object, because the stored object is not your file. Sync falls back to size and modification time. Use rclone cryptcheck secret: ./local to verify properly, and expect it to read data rather than just list it.
  • Version history becomes opaque: the provider still keeps old revisions, but you cannot preview or diff them in the web interface to decide which one you want. You restore blind, then decrypt to find out.
  • Trash and selective restore get clumsy: recovering one deleted file means identifying it by an encrypted name in a web UI, which in practice means restoring more than you need.

If you want deduplication and versioning back, that belongs in the tool above rclone. Restic and Borg both dedupe before encrypting, then push the result with rclone as a dumb transport.

Can you still sync across devices once crypt is in the way?

The native Dropbox and Google Drive clients are finished. They sync the plaintext folder on your disk, which is exactly what you are trying to avoid. You replace continuous background sync with something you schedule yourself.

  • rclone sync for one direction: the laptop is authoritative, the cloud is a mirror. Safe, simple, and it deletes anything on the destination that is gone locally. Always dry run first with --dry-run before trusting a new filter.
  • rclone bisync for two directions: this is the closest thing to the old behaviour. It needs --resync on first run to establish a baseline, and it stores state listings under ~/.cache/rclone/bisync/. Lose that state and you must resync again.
  • rclone mount for on demand access: the remote appears as a normal directory. Use --vfs-cache-mode writes at minimum, because many applications fail on a remote without write caching. Expect open and save latency measured in seconds, not milliseconds.
  • Scheduling instead of watching: rclone has no filesystem watcher driving uploads. You run it from cron or a systemd timer, typically every 5 or 15 minutes, so a change on one machine is not instantly visible on another.
  • Conflicts are yours to resolve: bisync renames both sides rather than merging. Edit the same document on two laptops within one sync window and you get two files, not a silent winner.
  • Mobile is the weak point: Android has third party crypt-aware clients such as Round Sync. On iOS there is no comparable maintained option, which rules crypt out for phone-first workflows.

Where do your crypt passwords and salt actually live, and how do you protect rclone.conf?

Run rclone config file to see the path, usually ~/.config/rclone/rclone.conf. Both the crypt password and the salt are written there, obscured rather than encrypted. Obscuring is reversible by design: anyone holding the file can recover the plaintext password with rclone reveal. Treat that file as the key itself, because it is.

  • Encrypt the config: in rclone config, choose "Set configuration password". The whole file is then encrypted at rest, and rclone prompts on every invocation unless you supply the password another way.
  • Automate carefully: RCLONE_CONFIG_PASS in the environment or --password-command "pass rclone/config" lets cron jobs run unattended. Both mean the unlock secret sits somewhere on the same machine, so you have traded a prompt for a slightly better hiding place, not for real protection.
  • Set permissions and check them: chmod 600 ~/.config/rclone/rclone.conf. On a shared box, a world readable config is the entire failure mode.
  • Keep it out of version control: dotfiles repositories, container images and Ansible playbooks have all leaked working rclone configs. Add the path to .gitignore before you commit anything.
  • Store the password and salt offline too: a password manager entry or a printed copy in a safe. The config file is a convenience copy, not your only copy.

The machine you choose shapes all of this. A laptop travels and gets stolen. A VPS is reachable from the internet permanently. A NAS at home, or a managed Personal Cloud Server such as Yundera running apps as Docker containers on a server dedicated to you, keeps the key material on hardware you can physically point at.

What happens if you lose the password, and how do you test a restore?

Nothing happens. That is the problem. There is no recovery flow, no support ticket, no key escrow. Lose the password and salt and your 500 GB of ciphertext is permanently unreadable, including by you. Dropbox and Google cannot help, because they never had the key. This is the price of the guarantee in the first place.

A restore drill is the only way to find out whether your setup works. Do it before you delete the local original, and repeat it on a schedule.

  • Rebuild from nothing, not from your working machine: copy only your recorded password and salt to a clean container or a spare laptop, run rclone config there, and recreate both remotes by hand. If you cannot do it from written notes alone, your notes are incomplete.
  • Restore a real subset: pull one full project directory with rclone copy secret:projects/2024-archive ./restore-test, not a single test file you uploaded yesterday.
  • Verify byte for byte: rclone cryptcheck secret:projects ./originals compares decrypted content against your local copy and reports differences explicitly. A successful download is not proof of a correct decryption.
  • Time it and write the number down: a 200 GB restore over a 100 Mbit connection takes hours. Knowing whether that is 4 hours or 14 changes what you tell a client when something breaks.
  • Test the config password path too: if the file is encrypted and unlocked by a script, confirm the manual password still works. People forget the one they automated away.

Run the drill every 6 months, and after any change to filename modes, provider or machine.

RClone with crypt vs a self-hosted alternative: which metadata does each expose?

Crypt protects content. Self-hosting protects context. The two answer different questions, and comparing them by metadata makes the gap obvious.

Metadata rclone crypt on Dropbox or Drive Self-hosted storage on your own server
File contents Hidden, ciphertext only Hidden from third parties, readable by you at rest unless you add encryption
Directory shape and file sizes Visible to the provider Never leaves your machine
Access times and frequency Logged by the provider on every operation Logged by you, in logs you can rotate or disable
Billing and account identity Tied to your name, card and IP Tied to your hosting provider or your electricity bill
Continued access Subject to the provider's terms and account actions Subject to your own hardware and backups
Legal exposure A request goes to Dropbox or Google, who hold metadata A request comes to you directly

The self-hosted column assumes something is actually running: Nextcloud for a sync client experience, or MinIO, Garage or SeaweedFS if you want an S3 endpoint that rclone can talk to natively. Any of those can run on a home NAS, a rented VPS or a Personal Cloud Server. On a managed Personal Cloud Server such as Yundera, apps are installed from an app store in one click and each is reachable on a public HTTPS subdomain via NSL.SH mesh routing, so no static IP, port forwarding or manual TLS certificate setup is involved.

The pragmatic answer is both. Self-host the primary copy, then use crypt to push an encrypted offsite copy to a provider you have decided not to trust.

Where should you run rclone: laptop, home server, NAS or VPS?

The machine that runs rclone must hold the plaintext, the keys and enough uptime to finish a transfer. Those three requirements rarely point at the same box.

  • A laptop: simplest, and the right answer if the data lives there anyway. The cost is that syncs only happen when the lid is open, and a 300 GB initial upload becomes a multi-day exercise in not closing it. Use --bwlimit 8M so the machine stays usable.
  • A NAS or a home server: always on, wired, and holding the authoritative copy. Synology and QNAP ship rclone in community repositories, and a Raspberry Pi 4 handles the cipher fine at typical domestic upload speeds. Schedule with a systemd timer rather than the vendor's task scheduler, which often drops environment variables.
  • A VPS: useful when you are moving data between two cloud services, because server side transfers never touch your home link. The catch is that your plaintext and your keys now sit on hardware someone else controls, which partly undoes the point of crypt.
  • A Personal Cloud Server: the same always-on model as a NAS without assembling it yourself. Yundera is one option here, alongside a self-managed VPS, a home server or a NAS.
  • Inside Docker: the official rclone/rclone image works, but rclone mount needs --device /dev/fuse and --cap-add SYS_ADMIN. If you only run sync or copy on a timer, skip both and keep the container unprivileged.

Pick the box that already stores the files. Every additional hop is another copy of plaintext to defend.

Top comments (0)