Proton Drive CLI:
Backups, Cron Jobs
and the Headless Login Problem

Date Published: 23 July 2026 Author: Baizaar Lee Last Updated: 23 July 2026
TL;DR:
Proton Drive CLI is Proton’s official command-line tool for uploading, downloading, managing and sharing Drive files on Linux, macOS and Windows. It runs one job and exits, so it handles scheduled backups and release uploads well and does not do background folder sync at all. The bit most guides skip: on a headless Linux box the login fails with a D-Bus keyring error until you wrap the command in dbus-run-session.
Download Proton Drive CLI from Proton, then start with a folder you can afford to get wrong. It runs on the free plan, so you can test the whole workflow before spending anything.
BAIZAAR may earn a commission if you sign up through the Proton links on this page. The free plan is genuinely free and it is where this guide tells you to start.
- What is Proton Drive CLI?
- Proton Drive CLI vs the desktop app: which do you need?
- Proton Drive CLI vs Rclone: Do you still need Rclone?
- Who Proton Drive CLI is for
- Before you touch a real backup
- How to install Proton Drive CLI
- Fixing "Cannot autolaunch D-Bus without X11 $DISPLAY"
- Signing in and testing access
- Proton Drive CLI commands worth knowing
- A Proton Drive backup script you can actually trust
- Scheduling a Proton Drive backup with cron
- Testing a restore
- What Proton Drive CLI cannot do yet
- Common Proton Drive CLI problems
- Should you use Proton Drive CLI?
- Related Proton Drive guides & Reviews
- Proton Drive CLI (FAQ)
What is Proton Drive CLI?
Proton Drive CLI is the official terminal interface for Proton Drive, built on the same Proton Drive SDK that powers the desktop and mobile apps. It ships as a single self-contained binary for Linux, macOS and Windows, and runs in any normal shell including Terminal, PowerShell and SSH.
Proton states that CLI operations carry the same end-to-end encryption as the rest of Proton Drive. Sign-in happens through your browser rather than by typing a password into the terminal, and the resulting session token is stored in the operating system’s credential store. That last detail causes most of the setup pain on servers, which is covered below.
At launch the CLI covers sign-in and sign-out, browsing and managing files and folders including trash, and sharing and invitations. Proton’s CLI support guide is the current command reference.
Proton Drive CLI vs the desktop app: which do you need?
The CLI runs a command, reports the result, and stops. It does not watch a folder and keep it matched with Drive in the background. Only the desktop applications include a full synchronisation engine.
That distinction decides the tool for you:
| Job | Better choice | Reason |
|---|---|---|
| Upload a backup archive every night | Proton Drive CLI | Runs from cron or Task Scheduler |
| Store build or release artefacts | Proton Drive CLI | One-off, repeatable, scriptable |
| Download an archive for a restore test | Proton Drive CLI | Retrieval can be scripted and logged |
| Snapshot a shared folder before an audit | Proton Drive CLI | Defined action at a defined time |
| Revoke a collaborator at offboarding | Proton Drive CLI | Written down as a command, not a click path |
| Keep Documents mirrored all day | Proton Drive desktop app | Background sync is an app feature |
| Any Drive automation on Linux | Proton Drive CLI | Currently the only official Linux option |
If you came here wanting a native Linux sync client, this is not it yet. Proton has said a full Linux desktop app is in development. See how to install Proton Drive on Linux for what exists today.
Proton Drive CLI vs Rclone: Do you still need Rclone?
Use the official CLI when you want a supported tool that will not break, and rclone when you need sync semantics or multi-cloud transfers the CLI does not offer.
The rclone Proton Drive backend was built by reading open-source client code and observing browser traffic, because Proton does not publish its API documentation. The rclone project marks that backend as beta and notes it may not work on every account. It does give you rclone sync, mounting, and copying straight between Proton Drive and another provider.
The official CLI gives you none of those, and in exchange gives you something Proton actually maintains and updates alongside the SDK. For a nightly archive upload, the official CLI is the lower-risk choice. For mirroring a directory tree with deletions propagated, rclone is still the only real option.
Who Proton Drive CLI is for
- Linux users who want official Proton Drive automation before the desktop app arrives
- Home-lab owners archiving configuration, documentation and database exports
- Developers pushing an archive after a build or release
- Small teams handing a defined folder to a reviewer with a record of it
- Anyone who wants a dated backup archive rather than another sync folder
It is not built for everyday document sync. That is a scope decision, not a defect.
Before you touch a real backup
- Pick a test folder with unimportant files.
- Create one destination folder in Drive, such as
/my-files/Backups/homelab. - Decide what must never enter the archive. Recovery phrases and raw API keys need an explicit exclusion rule, not an assumption.
- Write down how you will restore a file. A backup is only proven after a restore.
You do not need a paid plan for any of this. The free tier gives you 5 GB once you complete the setup steps Proton asks for, which is plenty for config files, documentation and database dumps. Storage is rarely the thing that pushes people to upgrade here, and the thing that does is covered later in the restore section.
For the limits of cloud encryption against a compromised device, see is Proton Drive actually private?
How to install Proton Drive CLI
Download the binary from Proton’s Drive download page, where the CLI sits alongside the full Drive client. If you would rather not use our link, the direct address is https://proton.me/drive/download and it will get you to exactly the same place.
Proton publishes checksums on that page. Match the checksum for your exact version and platform before running the file.
On Linux:
sha512sum proton-drive
On macOS:
shasum -a 512 proton-drive
Compare the result against the published checksum. This will not save a machine that is already compromised, but it catches a damaged or altered download, and it takes ten seconds.
Linux dependencies most guides miss
The binary is self-contained apart from two things it needs to store your session:
sudo apt-get install -y libsecret-1-0 dbus-x11
libsecret is the credential store interface. dbus-x11 provides dbus-run-session, which you will need in the next section. Fedora ships libsecret already, so you only need the D-Bus utilities there.
Make it executable
On Linux or macOS:
chmod +x proton-drive
./proton-drive version
On Windows, open PowerShell in the folder containing the downloaded file:
.\proton-drive version
Fixing “Cannot autolaunch D-Bus without X11 $DISPLAY”
Wrap the command in dbus-run-session. This error appears when you run the CLI over SSH or on a headless server, because the CLI wants to write its session token to the system keyring and there is no D-Bus session available to reach it.
dbus-run-session -- ./proton-drive auth login
dbus-run-session creates a temporary D-Bus session for the duration of the command, which makes the keyring reachable. On a graphical desktop this happens automatically and you will never see the error. On a server, every CLI call needs the same wrapper, including the ones inside your backup script.
This matters more than it looks. A login that works fine on your laptop will fail silently the first time cron runs it on the same machine, because cron has no session either. Test under the conditions the job will actually run in.
Signing in and testing access
Start browser-based authentication:
./proton-drive auth login
The CLI prints a URL. On a headless box, open that URL on any other device, complete the login there, and the terminal session picks up the result.
Then list the root of your Drive:
./proton-drive filesystem list /my-files
If that returns your files, the CLI can reach your account. Before running any command you have not used before, check its own help text:
./proton-drive filesystem upload --help
Flags change between releases. Proton’s support page is the source of truth, not a command sitting in a blog post from six months ago. This one included.
Proton Drive CLI commands worth knowing
Replace the paths below with your own, and test each command manually before handing it to a scheduler.
You do not have to type full command names. Any unambiguous short form works, and typing ./proton-drive on its own opens an interactive shell.
List a folder
./proton-drive filesystem list /my-files
Check the destination before you upload to it. A well-written script pointed at the wrong folder is still a mess.
Upload files
./proton-drive filesystem upload ~/Documents/* /my-files/Documents
For an archive folder where existing files should stay untouched:
./proton-drive filesystem upload ./reports/* /my-files/Reports --conflict-strategy skip
skip suits dated archives. It is the wrong choice for a folder where a newer file should replace an older one. Decide that before you automate it.
Download a folder
./proton-drive filesystem download /my-files/Reports ./backups
This is the command you need for a restore test, or for a local copy before travel.
Check and manage sharing
./proton-drive sharing status /my-files/Reports
./proton-drive sharing invite --user [email protected] --role editor /my-files/Reports
Check the current invite syntax with ./proton-drive sharing invite --help before adding anyone to a sensitive folder.
Control output for scripts
./proton-drive filesystem list /my-files --json
--json pipes cleanly into other tools. There are also verbosity controls worth knowing: quiet mode for jobs where you only care about failures, and verbose mode for interactive debugging. Check --help for the exact flags on your version.
A Proton Drive backup script you can actually trust
Uploading a folder is not a backup plan. A basic plan creates a dated archive, keeps a checksum, writes a log, and gets restored on a schedule.
- Create an archive from a known source directory.
- Exclude files that should not be copied.
- Generate a SHA-256 checksum for the archive.
- Upload the archive and checksum to one dedicated folder.
- Keep the job’s output.
- Download and test one archive on a regular schedule.
Review the source, destination and exclusions for your own system before using this pattern.
#!/usr/bin/env bash
set -euo pipefail
PROTON_DRIVE="$HOME/bin/proton-drive"
SOURCE_DIR="$HOME/homelab-config"
WORK_DIR="$HOME/backups/proton-drive-staging"
DESTINATION="/my-files/Backups/homelab"
STAMP="$(date +%Y-%m-%dT%H-%M-%S)"
ARCHIVE="$WORK_DIR/homelab-$STAMP.tar.gz"
LOG_FILE="$HOME/logs/proton-drive-backup.log"
mkdir -p "$WORK_DIR" "$(dirname "$LOG_FILE")"
tar \
--exclude='.git' \
--exclude='*.tmp' \
--exclude='*.env' \
-czf "$ARCHIVE" \
-C "$(dirname "$SOURCE_DIR")" \
"$(basename "$SOURCE_DIR")"
sha256sum "$ARCHIVE" > "$ARCHIVE.sha256"
dbus-run-session -- "$PROTON_DRIVE" filesystem upload \
"$ARCHIVE" "$ARCHIVE.sha256" \
"$DESTINATION" \
--conflict-strategy skip \
--json >> "$LOG_FILE"
Note the dbus-run-session wrapper on the upload line. Without it this script works when you run it by hand and fails when cron runs it, which is a genuinely annoying way to discover your backups stopped a fortnight ago.
The archive and checksum are still sensitive local files. Proton’s encryption protects the Drive operation. It does not protect a machine that can already read the source files.
Scheduling a Proton Drive backup with cron
Run the script manually first:
chmod +x "$HOME/scripts/proton-drive-backup.sh"
"$HOME/scripts/proton-drive-backup.sh"
Edit your crontab on Linux or macOS:
crontab -e
Run it nightly at 02:30 and log the result:
30 2 * * * /home/your-user/scripts/proton-drive-backup.sh >> /home/your-user/logs/proton-drive-cron.log 2>&1
Use full paths throughout. Cron does not load your usual shell environment, a fact most people discover at 02:31.
On Windows, create a Task Scheduler task calling the CLI or a PowerShell wrapper with full paths, and use the Run control once before trusting the schedule. Windows has no D-Bus, so the keyring wrapper does not apply there.
Testing a restore
A green upload message only tells you that an upload happened.
- Create an empty temporary folder, never your live configuration directory.
- Download a known archive and its
.sha256file. - Check the archive against the checksum.
- Extract it into a second temporary directory.
- Confirm expected files are present and excluded files are absent.
- Record the archive name, date and result.
mkdir -p "$HOME/restore-tests/proton-drive"
cd "$HOME/restore-tests/proton-drive"
dbus-run-session -- "$HOME/bin/proton-drive" filesystem download \
/my-files/Backups/homelab \
.
sha256sum -c homelab-YYYY-MM-DDTHH-MM-SS.tar.gz.sha256
mkdir extracted
tar -xzf homelab-YYYY-MM-DDTHH-MM-SS.tar.gz -C extracted
A matching checksum confirms the download matches the file you uploaded. It does not confirm you archived the right folder in the first place. Open the restored files and look at them.
The failure mode nobody plans for
The bad scenario is not a corrupted upload. It is a clean, verified, perfectly checksummed archive of a directory that was already broken.
You change something in a config file at the weekend. It quietly breaks a service you do not use every day. Your nightly job dutifully archives the broken state, encrypts it, uploads it, logs a success, and does the same thing every night for three weeks. Every checksum matches. Every log line is green. Then you actually need to restore, and the only versions you have are all wrong.
Retention is the only real defence, and this is where the free plan stops being adequate for backups specifically. Proton Drive’s free tier keeps older file versions for seven days. If a problem takes longer than a week to surface, and quiet ones usually do, the good copy has already gone. Paid plans hold up to 200 versions of a file for up to ten years.
That is the honest reason to consider upgrading, and it has nothing to do with running out of space. If your archives matter enough to script, they probably matter enough to keep a version of from before whatever you have not noticed yet.
Proton Drive Plus is currently £1, $1 or €1 for the first month on the monthly plan, which is enough to test whether ten-year version history changes how you sleep. On annual billing it works out at £1.94 per month in the UK, or $2.99 and €2.99 elsewhere, for 200 GB. Proton’s own pricing page will confirm the current figures before you commit.
The NIST Cybersecurity Framework treats recovery planning as a core function rather than an afterthought. Plan the way back before you need it.
Keeping it tidy
- Use a unique Proton password and multi-factor authentication.
- Verify new binaries before running them.
- Restrict local access to scripts, staging folders and logs.
- Never put passwords, recovery phrases or raw secrets in a shell script.
- Exclude
.envfiles and key material explicitly rather than hoping. - Keep archives separate from working files.
- Avoid re-uploading unchanged data. Proton’s fair-use limits can affect unusually high traffic.
- Check sharing status before inviting anyone.
- Restore something on a schedule, not only after a disaster.
That first point is worth sitting with. The CLI’s whole security model rests on your Proton account, because the session token in your keyring is the thing standing between a stolen laptop and your entire archive. A reused password undoes every other precaution on this list.
If you are already paying for a password manager and a VPN separately, the arithmetic on Proton Unlimited is worth a look. It bundles 500 GB of Drive storage with Proton Pass, Proton VPN, Proton Mail and Sentinel account protection, at £7.27 per month in the UK on annual billing, or $9.09 and €9.09 elsewhere. The same £1, $1 or €1 first-month offer applies if you want to try it before committing to a year.
Whether that is good value depends entirely on what you already pay for. If you have no interest in the VPN or the mailbox, Drive Plus is the cheaper and more sensible answer, and this article is not going to pretend otherwise.
What Proton Drive CLI cannot do yet
Proton Drive CLI does not provide continuous background sync. Only the desktop applications include a full synchronisation engine.
Proton has also listed photo and album management, public-link sharing, and multi-account switching as future additions. Treat those as roadmap, not features.
| Need | Current answer |
|---|---|
| Live two-way sync | A supported Proton Drive desktop app |
| Native Linux desktop client | In development, not released |
| Official command-line actions on Linux | Available now |
| Photo or album management from a script | Not currently supported |
| Public share links from a script | Not currently supported |
| One automation across several accounts | Not currently supported |
True sync semantics with deletions | rclone’s beta backend, not the official CLI |
Common Proton Drive CLI problems
“Cannot autolaunch D-Bus without X11 $DISPLAY”
Wrap the command with dbus-run-session --. See the section above. Install dbus-x11 and libsecret-1-0 if the wrapper itself is missing.
“Permission denied”
On Linux or macOS, the downloaded file is not executable yet:
chmod +x proton-drive
./proton-drive version
It works manually but fails on a schedule
Two usual causes. The scheduled environment does not know your PATH or working directory, so use full paths for the CLI, source, destination and log file. And on Linux there is no D-Bus session, so add the dbus-run-session wrapper inside the script rather than relying on your interactive shell.
The upload worked but the file seems missing
List the target folder before automating the job, and use one dedicated folder for backups. Path mistakes have excellent timing.
You actually need live sync
Use a desktop sync app on a supported platform, or rclone if you are on Linux and accept a beta backend. The CLI will not become a background daemon no matter how you configure it.
Should you use Proton Drive CLI?
Use it if the work is a defined transfer or a scheduled archive, and somebody is willing to own the restore test. It suits Linux users, build artefacts, home-lab backups and review folders.
Skip it if you need constant two-way sync, or if nobody will check that the job still runs. A backup script nobody checks is a liability with good intentions.
Get Proton Drive CLI from Proton once you have a test folder and a restore plan. That is the correct order.
Start on the free plan. Get one job running, prove the restore works, and only then decide whether seven-day version history is enough for you or whether you want the ten-year kind. Making that call after you have seen your own restore drill is a great deal more useful than making it now.
Related Proton Drive guides & Reviews
- How to install Proton Drive on Linux
- Is Proton Drive actually private?
- Proton Drive vs pCloud in 2026
Proton Drive CLI (FAQ)
Is Proton Drive CLI official?
Yes. Proton builds and supports Proton Drive CLI on top of the Proton Drive SDK, the same foundation as the official desktop and mobile apps. Unofficial third-party Proton Drive CLI projects also exist on GitHub, which are not the same thing.
Does Proton Drive CLI work on Linux?
Yes. Proton provides the CLI for Linux, macOS and Windows. On Linux it is currently the only official option, since the native desktop client is still in development.
Can Proton Drive CLI sync folders automatically?
No. It automates upload, download, file management and sharing commands, but it does not keep a local folder continuously synchronised. Proton states that only the desktop applications include a full background synchronisation engine.
Why does Proton Drive CLI fail with a D-Bus error over SSH?
Because the CLI stores its session token in the system keyring, and a headless or SSH session has no D-Bus session to reach it. Wrap the command in dbus-run-session -- and install dbus-x11 and libsecret-1-0.
Can I schedule a Proton Drive backup?
Yes. Run the CLI from cron, Task Scheduler or another scheduler. Test the command manually first, include the dbus-run-session wrapper on Linux, and schedule a restore test alongside the upload.
Is Proton Drive CLI end-to-end encrypted?
Proton states that CLI operations carry the same end-to-end encryption as Proton Drive. Your device still matters, since malware with local read access can see files before an upload begins.
Proton Drive CLI or rclone: which should I use?
Use the official CLI for supported, maintained one-shot jobs like scheduled archive uploads. Use rclone if you need sync semantics, mounting, or transfers between Proton Drive and another cloud provider, accepting that its Proton backend is beta and reverse-engineered.
Does Proton Drive CLI work on the free plan?
Yes. The CLI is not a paid feature, and every command in this guide runs on a free Proton account with 5 GB of storage. The limitation that matters for backups is not space, it is version history: the free plan keeps older file versions for seven days, whereas Drive Plus and Unlimited keep up to 200 versions for up to ten years.
Is Proton Drive Plus or Proton Unlimited better for CLI backups?
Drive Plus if you only want storage, Unlimited if you would otherwise pay separately for a VPN and a password manager. Drive Plus gives 200 GB at £1.94 per month in the UK on annual billing, or $2.99 and €2.99 elsewhere. Unlimited gives 500 GB plus Proton VPN, Pass, Mail and Sentinel at £7.27, $9.09 or €9.09 per month annually. Both currently offer a £1, $1 or €1 first month on monthly billing. Check Proton’s pricing page for current figures, since introductory offers change.
Can a small team use Proton Drive CLI?
Yes, for specific jobs such as uploading a report archive, checking sharing before a handover, or revoking access when someone leaves. It does not currently support switching between multiple accounts, so it is not a full managed-service workflow.
Last checked: 23 July 2026. Commands, flags and feature support change between releases. Check Proton’s official CLI support guide before deploying a new job.


