Read this in French / Français.
Automatic two-way synchronisation of Proton Drive on Linux, using rclone bisync and a systemd user timer.
Proton does not ship a Linux sync client. This repository provides a working setup, tuned to avoid the API rate limits (HTTP 429 errors) that most rclone users hit with Proton Drive.
Tested on Kali Linux (rolling), with two machines syncing to the same remote folder.
- How it works
- Requirements
- Installation
- Multi-machine setup
- Rate-limit tuning
- Day-to-day usage
- Troubleshooting
- Performance
- Known limitations
A systemd user timer periodically triggers a oneshot service that runs rclone bisync between a local folder and a remote Proton Drive folder.
~/Proton drive/ <──── rclone bisync ────> proton:kali/
(local) (remote)
▲ ▲
│ │
systemd timer Proton Drive API
(every ~20 min) (via rclone backend)
bisync was chosen over sync on purpose: sync is one-way and destructive, whereas bisync propagates changes in both directions and handles conflicts.
A FUSE mount (rclone mount) was ruled out: the cache drifts out of sync and writes from several machines cause problems, since the Proton Drive API provides no real-time change events.
- A Linux distribution with systemd
- A Proton account with Proton Drive enabled
rclone≥ 1.63 (theprotondrivebackend does not exist before that)
⚠️ Thercloneversion packaged by most distributions is too old. Use the official install script.
sudo -v ; curl https://rclone.org/install.sh | sudo bash
rclone --version # must report >= 1.63mkdir -p ~/"Proton drive"
mkdir -p ~/.local/share/rclone-proton
⚠️ Required step. Log in at least once to https://drive.proton.me from a browser before configuring rclone. Without this, the encryption keys are never generated on Proton's side and authentication fails.
rclone config| Prompt | Answer |
|---|---|
| Action | n (New remote) |
| name | proton |
| Storage | protondrive |
| username | your Proton email address |
| password | your Proton password |
| 2FA | TOTP code, or leave empty if not enabled |
| Advanced config | n |
The remote name (proton) is just a local alias stored in ~/.config/rclone/rclone.conf. It has nothing to do with your Proton subscription.
Check it works:
rclone lsd proton: # the trailing colon is mandatory
rclone mkdir proton:kaliRun this once per machine. It establishes the baseline state that bisync needs in order to detect later changes.
rclone bisync ~/"Proton drive" proton:kali --resyncmkdir -p ~/.config/systemd/user
cp systemd/rclone-proton.service ~/.config/systemd/user/
cp systemd/rclone-proton.timer ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now rclone-proton.timerOr use the provided script:
./install.shsystemctl --user list-timers rclone-proton.timer # next scheduled run
systemctl --user start rclone-proton.service # run a sync right now
tail -f ~/.local/share/rclone-proton/bisync.log # follow the log liveRepeat steps 1 to 6 identically on every machine. Step 6 (deploying the systemd units) is required on each machine, not only the first one.
Two possible strategies:
| Strategy | Remote folder | Result |
|---|---|---|
| Shared | proton:kali on both machines |
Both machines see the same files |
| Isolated | proton:kali and proton:laptop |
Each machine keeps its own space |
If the same file is modified on both machines between two sync cycles, --conflict-resolve newer keeps the most recent version and the other one is lost. Other accepted values are larger, path1 and path2.
RandomizedDelaySec=5min in the timer naturally drifts the machines apart over time, so they do not hit the Proton API at the same instant.
Proton states that it does not actively block rclone, but that the way rclone synchronises files triggers the anti-abuse mechanisms meant to keep infrastructure usage fair. 429 Too Many Requests errors on api/auth/v4 are common with default settings.
Options used in the service:
| Option | Purpose |
|---|---|
--tpslimit 4 |
Caps API calls at 4 per second |
--checkers 3 |
Limits parallel checks |
--modify-window 1s |
Tolerance on modification timestamps |
--protondrive-replace-existing-draft=true |
Resumes interrupted uploads instead of failing |
--resilient |
Keeps going through transient errors |
--recover |
Recovers cleanly after an interruption |
On the systemd side, TimeoutStartSec=0 disables the default 90-second timeout, which would otherwise kill any sync running longer than a couple of minutes.
A VPN with a shared exit IP (including Proton VPN) can make things worse: the address is shared with other users hitting the same API. It is not the root cause, but it is a plausible aggravating factor.
# Run a sync immediately
systemctl --user start rclone-proton.service
# Service and timer status
systemctl --user status rclone-proton.service
systemctl --user list-timers rclone-proton.timer
# Logs
tail -50 ~/.local/share/rclone-proton/bisync.log
journalctl --user -xeu rclone-proton.service
# Pause / resume synchronisation
systemctl --user disable --now rclone-proton.timer
systemctl --user enable --now rclone-proton.timerThe colon is missing. Use rclone lsd proton: — without it, rclone looks for a local folder.
A bisync safeguard: more than half of the known files have disappeared. This is expected after a large but legitimate deletion.
# Force this single run
rclone bisync ~/"Proton drive" proton:kali --force ...
# Or start from a clean baseline
rclone bisync ~/"Proton drive" proton:kali --resyncThis is a rate limit on authentication, not on transfers: every bisync run opens a new session.
- Increase the timer interval (
OnUnitActiveSec) - Confirm that
--tpslimitand--checkersare actually applied - Wait a few minutes; retrying in a loop only makes the block worse
- Try without a VPN to rule out the shared-IP effect
The systemd message is rarely informative. The real cause is in the rclone log:
tail -50 ~/.local/share/rclone-proton/bisync.logA Checks counter sitting at 100% for several minutes with no transfer usually means silent retries in the background (--resilient does not log every attempt at INFO level). Make sure TimeoutStartSec=0 is present in the service unit.
Sync duration depends on the number of files, not on the amount of data.
Measured on a library of roughly 23,000 files (~6 GB):
| Situation | Duration |
|---|---|
| No changes | ~8 min 35 s |
| One file added | ~13 min |
Most of that time is spent in the Building Path1 and Path2 listings stage, i.e. enumerating the remote content through the Proton API, which is capped by --tpslimit and --checkers.
Worth noting: bisync computes no hashes by default. Comparison relies on modification time and size ("Checksum": false). The cost is therefore not cryptographic but purely a matter of API call volume.
Practical consequences:
- Going from 6 GB to 500 GB at a constant file count does not slow the sync down
- Multiplying the number of small files slows it down proportionally
- The timer interval must stay longer than the real duration of a sync, otherwise runs overlap
Possible optimisations if needed: exclude folders full of small files (--exclude), raise --tpslimit cautiously, or test --fast-list.
rclone bisyncis marked BETA upstream — do not rely on it as your only backup- No real-time sync: propagation delay equals the timer interval
- The Proton Drive API is not public; the rclone backend relies on reverse engineering and may break when Proton changes something
- Concurrent edits on two machines between two cycles cause the older version to be lost
MIT — see LICENSE.