rclone crypt: encrypt files client-side before they touch any cloud

If you want files encrypted before they ever reach a cloud provider — so the provider only ever sees ciphertext — rclone crypt is the simplest tool that works with almost any backend (S3, Google Drive, Dropbox, pCloud, Backblaze B2, a plain SFTP box…). This is client-side, zero-knowledge-style encryption you fully control. Here's a clean setup.

The idea

rclone crypt is a wrapper remote: it sits on top of a normal remote and transparently encrypts file contents and file/dir names on the way up, decrypts on the way down. Your passphrase never leaves your machine.

local files  ->  [crypt remote: encrypt]  ->  [storage remote]  ->  cloud (sees ciphertext only)

1. Install

curl https://rclone.org/install.sh | sudo bash

# or: sudo apt install rclone

rclone version

2. Configure the underlying storage remote

rclone config

# n) New remote -> name it e.g. "drive" -> pick your provider -> OAuth/keys

Test it:

rclone lsd drive:

3. Add a crypt remote on top

rclone config

# n) New remote -> name "secret" -> storage: "crypt"

#   remote>  drive:encrypted        # a subfolder on the storage remote

#   filename_encryption>  standard  # also encrypts file names

#   directory_name_encryption>  true

#   password>  (generate a strong one)

#   password2>  (salt - optional but recommended)

Back up the passphrase + salt in a password manager. There is no recovery if you lose them — that's the whole point of zero-knowledge.

4. Use it

# Upload (everything is encrypted client-side first):

rclone copy ~/Documents secret: -P



# List (decrypted view, local only):

rclone ls secret:



# Mount as a normal folder:

rclone mount secret: ~/CloudCrypt --vfs-cache-mode writes

On the provider's side you'll see only opaque names like a1b2c3d4... — no filenames, no content.

5. Verify the provider sees nothing

rclone ls drive:encrypted    # raw view = encrypted blobs + scrambled names

If you can read filenames here, filename encryption isn't on — recheck step 3.

Gotchas

• 
  crypt encrypts content + names, not the number of files or their sizes. A motivated observer can still infer file count and approximate sizes. For metadata-sensitive cases, pad or archive first.


• 
  It does not add redundancy. crypt is encryption, not backup — keep the 3-2-1 rule.


• 
  Two different crypt remotes with different passwords are incompatible. Decide your scheme once.

When a provider-native E2E option is better

rclone crypt is great for bolting encryption onto any backend. But if you want native end-to-end encryption, mobile apps, and sharing built in, a zero-knowledge provider may fit better. The trade-offs between "encrypt-it-yourself" and provider-native E2E/zero-knowledge are worth understanding:

→ End-to-end vs zero-knowledge cloud storage — what's the real difference