dhy@ironhide: ~/site
dhy@ironhide:~/site$cat header.html
_____ _ _ _ _ | __ \| | | | | | | | | | | |_| | | | | | | | | _ | |_| | | |__| | | | | _ | |_____/|_| |_|_| |_| ~/dhy.tr — personal notes & technical writing
dhy@ironhide:~/site$ls -la *.md

Mounting Google Drive with rclone and Encrypted Backups with Crypt

Backups are one of those things everyone agrees they should set up, but few actually do. Until the disk dies, the file gets deleted, or the cloud account gets suspended — at which point you wish you'd configured it properly weeks ago. In this article, I'll walk through mounting Google Drive with rclone, layering crypt on top for client-side encryption, and automating the whole thing. End to end.

Zero to production, without skipping the conceptual model.

Why rclone + crypt?

Most people ask: "Isn't Google Drive already secure?" Short answer: Drive encrypts your files at rest, but with Google's own keys. If your Google account gets compromised (phishing, stolen password, insider breach) the files are readable. Worse: in some jurisdictions, providers can be legally compelled to hand over user data.

The crypt layer solves this. rclone encrypts files client-side, in your system's RAM, then uploads the encrypted blob to Drive. If Google (or anyone) looks at the files in your Drive, they see NaCl SecretBox formatted random bytes. The key stays with you — without it, decryption is computationally infeasible.

Three critical benefits:

  1. Zero-knowledge — the provider cannot see your content
  2. Portability — switching from Drive to Dropbox, S3, or B2 tomorrow works with the same crypt layer (crypt wraps any remote)
  3. Repudiation — even if Drive is pressured to terminate your account for "suspicious encrypted backups," the content remains unreadable

Installation

Step 1 — Install rclone

# Debian/Ubuntu
sudo apt install rclone

# Arch
sudo pacman -S rclone

# macOS (Homebrew)
brew install rclone

# Static binary (any platform)
curl https://rclone.org/install.sh | sudo bash

Verify the install:

rclone version
# rclone v1.69.0 (current major; crypt includes everything needed for this guide)

Step 2 — Google Cloud project and OAuth client

This step is technical but unavoidable. rclone's default client_id is shared across all users and has a shared quota of ~750 GB/day — exceed it and you'll get "rate limit exceeded" errors. Creating your own client_id lifts this limit.

  1. Go to https://console.cloud.google.com
  2. Top bar → "Select a project" → "New project", name it rclone-backup
  3. Left menu → APIs & Services → Library → find Google Drive API → click Enable
  4. APIs & Services → OAuth consent screen:
    • User type: External
    • App name: rclone-backup
    • Don't touch scopes yet
    • Under Test users, add your Google account email (since you haven't published the app, only test users can authorize)
  5. APIs & Services → Credentials → Create Credentials → OAuth client ID:
    • Application type: Desktop app
    • Name: rclone-desktop
    • Click Create → you'll get a client_id and client_secret. Save these (you'll need them next)

You don't have to publish the OAuth consent screen to "In production." Test mode is fine — the key is adding your account to test users.

Step 3 — Add the Google Drive remote

rclone config

Follow the wizard:

No remotes found, make a new one?
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n

name> gdrive           # short name; crypt layer will reference this

Storage> drive         # select "drive" from the list (Google Drive)

client_id> <client_id from step 2>
client_secret> <client_secret from step 2>

scope> 1               # 1 = Full access (needed for backups)
                        # Read-only is also available if you don't need to write

service_account_file>  # leave blank, just press Enter

root_folder_id>        # leave blank to use "My Drive" root

Configure this as a Shared Drive?
y/n> n                 # for personal Drive, say n

Use auto config?
y/n> y                 # y on a desktop with a browser; n on a headless server (covered below)

Use auto config will open a browser and prompt you to sign in to your Google account. The browser auto-grants the requested scopes and returns a token to the terminal. Don't lose this token — it's used for every Drive access.

On a headless server (SSH, no GUI), say n to auto config. rclone will give you a URL — open it in a browser on your laptop, grant access, paste the resulting code back into the terminal. This is rclone's official "remote setup" method.

End with y to confirm. You're out:

Current remotes:

Name                 Type
====                 ====
gdrive               drive

Test it:

rclone lsd gdrive:
# Lists the top-level folders in your Drive

The Crypt Layer: Encrypt Your Files

Now we wrap the Drive remote with a crypt layer. This is a separate remote — gdrive accesses Drive directly, while vault (or whatever you name it) encrypts everything under gdrive:encrypted/.

Step 4 — Create the crypt remote

Back to rclone config:

n) New remote
name> vault

Storage> crypt          # select "crypt" from the list

Remote to encrypt/decrypt>
remote> gdrive:encrypted
# The remote + path that crypt will wrap.
# An "encrypted" folder will be created in Drive if it doesn't exist.

How to encrypt the filenames?
filename_encryption>
# 3 options:
#   1 / standard  — file and directory names encrypted (~143 character limit)
#   2 / obfuscate — simple rotation, mild obfuscation (not strong, but allows longer names)
#   3 / off       — no name encryption, just adds ".bin" extension
#
# Recommendation: **1 (standard)**. Secure, file names become completely unreadable.
# Only use obfuscate if long paths (200+ chars) are critical for your workflow.

Option to either encrypt directory names or leave them intact.
directory_name_encryption>
# true  — directory names also encrypted (most secure)
# false — directory names left as-is
#
# Recommendation: **true**. With true, `/Users/davuthan/Documents/2024/tax.pdf`
# becomes `p0e52nreeaj0a5ea7s64m4j72s/l42g6771hnv3an9cgc8cr2n1ng/qgm4avr35m5loi1th53ato71v0`
# in Drive. The entire path structure is hidden.

Password or pass phrase for encryption.
y) Yes, type in my own password
g) Generate random password
y/g> y

Enter the password:
password: **********
Confirm the password:
password: **********

# Second password = salt. Diversifies the encryption key.
# Same password with different salt produces different keys.
# Recommendation: **set the second password manually too**, make it different and long.
y) Yes, type in my own password
g) Generate random password
y/g> y
Enter the password:
password: **********
Confirm the password:
password: **********

Crypt remote ready. rclone config now shows:

Name                 Type
====                 ====
gdrive               drive
vault                crypt

Step 5 — Test

# Write a file through vault
echo "encrypted secret data" > /tmp/secret.txt
rclone copy /tmp/secret.txt vault:test/

# What does Drive see?
rclone lsf gdrive:encrypted/
# j4k3lq8x... bin       (encrypted name, "bin" extension)

# Read it back
rclone cat vault:test/secret.txt
# encrypted secret data   (decrypted on-the-fly)

# Size overhead
rclone size gdrive:encrypted/
# Total:  123 B    (each file gets 24-byte overhead + content)

At this point you should notice: in the Drive web UI, when you navigate to the encrypted/ folder, file names look like random hex/base64 strings, and Drive cannot preview their content. This is expected.

rclone.conf Encryption (Advanced)

After the above steps, your ~/.config/rclone/rclone.conf looks like:

[gdrive]
type = drive
client_id = xxx.apps.googleusercontent.com
client_secret = xxx
token = {"access_token":"...","refresh_token":"...","expiry":"..."}

[vault]
type = crypt
remote = gdrive:encrypted
filename_encryption = standard
directory_name_encryption = true
password = s8d7g6f5d4s3a2s1_    # base64 encoded
password2 = 9j8h7g6f5d4s3a2_   # salt

Problem: password and password2 are stored in lightly-obscured form (base64 + obfuscation). Anyone reading this file can decrypt your data. So we need to encrypt the rclone.conf itself:

rclone config
s) Set configuration password

Enter a password twice (use a different password from the crypt one — if one is compromised, the other remains safe). rclone will now require this conf password on every command. If you lose this password, you lose access to rclone.conf — back it up, store it in your password manager.

Backup: Copy, Sync, Mount

One-off copy

# Back up a specific folder
rclone copy ~/Documents vault:backup/documents

# See progress
rclone copy ~/Documents vault:backup/documents -P
# Transferred:   45.2 MiB / 230.5 MiB, 19%, 12.4 MiB/s, ETA 15s

Continuous sync

copy doesn't remove deleted files on the destination; sync does:

# Keep the Documents folder in sync with Drive
# (files deleted locally WILL be deleted on Drive!)
rclone sync ~/Documents vault:backup/documents

⚠️ WARNING: rclone sync is unidirectional and destructive. Anything not in the source is removed from the destination. Reverse the order by mistake (Drive → local) and you lose your entire backup. Always:

  1. Run rclone sync --dry-run first to preview
  2. Get the order right: local → remote (source left, destination right)
  3. Use --interactive or -i to confirm each deletion

Mount: Use Drive as a filesystem

# Create an empty mount point
mkdir -p ~/DriveVault

# Mount the crypt remote
rclone mount vault: ~/DriveVault --vfs-cache-mode full
# Runs in the foreground; Ctrl+C to stop

Now ~/DriveVault shows your files in their original, decrypted form. Open them in a file manager, edit them — rclone intercepts file accesses in the background and encrypts/decrypts transparently.

Because it's FUSE-based, there are limitations: file locking doesn't work properly, large files have a delay on first access. Use sync for backups/archives, mount for interactive day-to-day file access.

Mount as a systemd service

Auto-mount at login:

~/.config/systemd/user/rclone-vault.service (user-level):

[Unit]
Description=rclone mount for vault (Google Drive crypt)
After=network-online.target

[Service]
Type=notify
ExecStart=/usr/bin/rclone mount vault: /home/davuthan/DriveVault \
    --vfs-cache-mode full \
    --vfs-cache-max-age 72h \
    --vfs-read-chunk-size 128M \
    --vfs-read-chunk-streams 4 \
    --dir-cache-time 30m \
    --poll-interval 1m
ExecStop=/bin/fusermount -uz /home/davuthan/DriveVault
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable rclone-vault
systemctl --user start rclone-vault
systemctl --user status rclone-vault

Automation: cron / systemd timer

The cleanest way to schedule daily backups is a systemd timer. cron works too, but systemd gives you OnFailure= notifications, journal logging, and persistent state for free.

~/.config/systemd/user/backup-documents.service:

[Unit]
Description=Daily encrypted backup of Documents to Google Drive
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/bin/rclone sync \
    /home/davuthan/Documents \
    vault:backup/documents \
    --log-file /home/davuthan/.local/share/backup-documents.log \
    --log-level INFO
Nice=10

~/.config/systemd/user/backup-documents.timer:

[Unit]
Description=Daily encrypted backup schedule

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup-documents.service

[Install]
WantedBy=timers.target

systemctl --user daemon-reload
systemctl --user enable --now backup-documents.timer
systemctl --user list-timers
# NEXT                        LEFT     LAST                        PASSED  UNIT
# 2026-06-05 03:00:00 +03     16h left 2026-06-04 03:00:14 +03     15min ago backup-documents.timer

For failure notifications, add:

[Unit]
...
OnFailure=notify-failure@%n.service

and define a [email protected] template (telegram, email, whatever). For a minimal setup, journal log is enough.

The Ugly Truths of Google Drive (Limits)

rclone + Drive + crypt isn't perfect. Google's API limits can bite you:

Rate limiting: Drive caps transfers at about 2 files/second. Even if a single file is 100 MB, it still counts as one transfer. This is why backing up many small files can take hours. Workaround: use --transfers 4 --checkers 8 for parallel transfers (carefully — exceeding rate limits triggers a 24-hour cooldown).

User rate limit exceeded: If you use rclone's default shared client_id, you're subject to a 750 GB/day shared quota. Exceed it and you get rate-limited for 24 hours. Creating your own client_id removes this limit (only your account is affected, effectively unlimited).

Duplicated files: Drive sometimes duplicates uploaded files. rclone logs warnings about this. Fix with:

rclone dedupe gdrive:encrypted/
# or, preferably, through the crypt layer (works transparently)
rclone dedupe vault:

Missing SHA-1/SHA-256: All Drive files have an MD5 hash, but SHA-1/SHA-256 are only present for files uploaded after 2018. If you have older backups and need hash verification, use MD5. rclone uses whatever is available.

Large files: Drive supports up to 5 TB per file (rclone handles this transparently). For files larger than 5 TB, use the rclone chunker:

# Chunker with 50 GB chunks
rclone config
# storage: chunker
# remote: gdrive:large-files
# chunk_size: 50G

Chunker for Very Large Files

You can stack crypt + chunker (crypt handles content, chunker handles size). Layout:

local 5 TB file
    → vault  (crypt, encrypts)
        → chunker  (splits into 50 GB chunks)
            → gdrive:large-files  (Drive, uploads chunks)

Don't reverse the order (gdrive → chunker → crypt doesn't work — chunker can't split already-encrypted files cleanly).

rclone.conf stack:

[gdrive]
type = drive
...

[vault]
type = crypt
remote = gdrive:encrypted
...

[vault-big]
type = chunker
remote = vault:big-files
chunk_size = 50G

Usage:

# Back up a 5 TB disk image
rclone copy /mnt/disk-image.img vault-big:

rclone tree vault-big: output:

/ 5.0 TiB
  disk-image.img
    .disk-image.img_2026-06-04_a.7z  50G
    .disk-image.img_2026-06-04_b.7z  50G
    ...

Integrity Verification

Are your backed-up files actually intact, or did Drive silently corrupt something? Verify with:

# Compare local against crypt-encrypted copy
rclone check ~/Documents vault:backup/documents
# Should print "0 differences"

# Compare two different backup locations (e.g., two separate Drive accounts)
rclone check vault:backup vault2:backup

If you set up crypt remotes with the same passwords, you can compare directly on the encrypted files — no decrypt/re-encrypt cycle, very fast.

Recovery Scenario

"Tomorrow my Drive account gets suspended, how do I get my files back?"

Simulating the worst case:

  1. Keep your rclone.conf and crypt passwords in a safe place (password manager)
  2. On a fresh machine, install rclone
  3. Create a new Google account, set up Drive the same way
  4. Download the encrypted/ folder from Drive (rclone, browser, anything works)
  5. rclone config to create a crypt remote (same passwords)
  6. rclone mount vault: ./recovered or rclone copy vault: ./recovered

If the passwords are correct, the encrypted blobs transparently decrypt to your original files. Wrong passwords = NaCl SecretBox can't decrypt = files are garbage. That's why:

  • Back up passwords in multiple places (password manager + sealed paper envelope in a safe)
  • Back up rclone.conf too (crypt passwords are in there in obscured form — still a problem if leaked, but needed as a backup)
  • Never store crypt passwords only in your head

Conclusion

What makes this setup great:

  • Zero-knowledge — the provider cannot see your content
  • Portable — switching from Drive to B2 tomorrow keeps the crypt layer intact
  • Transparent — with mount, files behave like normal local files
  • Free — Google's 15 GB is enough, crypt + chunker add no extra cost
  • Automated — systemd timer runs nightly with zero manual intervention

Critical points for the setup:

  1. Create your own OAuth client_id (avoids shared quota issues)
  2. filename_encryption = standard and directory_name_encryption = true (full obfuscation)
  3. Enable rclone.conf encryption
  4. Automate with systemd timer, monitor via journal log
  5. Back up passwords in multiple secure places, never memorize them alone

Don't:

  • Use the default client_id for high-volume backups (you'll hit rate limits)
  • Skip --dry-run before rclone sync (data loss risk)
  • Store passwords only in your head (lose them = lose data)
  • Use off filename encryption (defeats half the security model)

Further reading:

This article is a personal backup guide published on dhy.tr. For questions or corrections, reach out via the contact page.

dhy@ironhide:~/site$