Proton Drive on Linux: The State of Play in October 2026

Proton Drive has offered its own sync clients for Windows and macOS since 2023. On Linux, there is currently the web interface, community tools, and, since June 2026, an official command-line application, but no sync client yet. The situation is even more difficult on a server, where neither desktop sync nor interactive sign-in is a good fit.

This overview describes the state of play as of October 1, 2026. It is based on the published roadmaps, the source code of the Proton Drive CLI, and a practical test of the Rclone backend as document storage for Paperless-ngx.

Update from October 1, 2026: The first version from July 26 described the command-line application merely as a tool in the SDK repository. However, Proton had already officially released it as the Proton Drive CLI on June 9, 2026, with ready-made builds for Windows, macOS, and Linux. The related section and the recommendation table have been updated accordingly; the details are covered in a separate article about the Proton Drive CLI.

The Linux client has been announced, but there is still no date

In June 2026, Proton explicitly confirmed for the first time that a Linux client is being developed. It is being built on the new, unified SDK and is intended to use the same technical foundation as the Windows and macOS applications. As of early October 2026, there is still neither a release date nor a public beta.

Important context: this will be a desktop sync client. It solves the problem for desktop use. For server applications, however, a sync client is the wrong tool, because a service needs to read files directly from Proton Drive and write files to it. A sync client maintains a complete local copy, exactly what you want to avoid when storage is limited.

Rclone remains necessary for mounts and mirroring

On Linux, Rclone with its protondrive backend is currently the most versatile tool. It can copy and synchronize files and, as the only available solution, provide Proton Drive as a local directory through a FUSE mount. Two limitations are important:

It is beta software using a reconstructed API. Proton does not publicly document its Drive API; the backend is based on reverse engineering. In testing, it worked reliably, but throttled rapid sequences of calls with inconsistent directory listings.

For unattended operation, Rclone asks for the TOTP key. The configuration wizard labels the field otp_secret_key. This means the permanent key from the 2FA setup, not the six-digit code currently displayed by an authenticator app. Rclone stores this value obfuscated and generates a valid TOTP code from it for every sign-in.

Anyone who accidentally enters a current one-time code can complete the initial sign-in. However, the next reauthentication fails with error 8002 because Rclone cannot use the same code again.

This keeps the account protected against an isolated stolen password. However, a compromised server exposes both the password and the TOTP key. A dedicated Proton account is therefore recommended for automated access.

How such a mount behaves in Docker environments, including two undocumented issues, is covered in the separate article on Rclone in containers.

The official CLI covers scripts and backups

On June 9, 2026, Proton released the Proton Drive CLI, a single executable proton-drive for Windows, macOS, and Linux. It is based on the same SDK as the official apps; the source code is in the public SDK repository. The current version is 0.9.0, dated October 5, 2026, with builds for x86-64 (including without AVX2), ARM64, and musl distributions such as Alpine.

The sign-in model is cleaner than that of the Rclone backend:

• auth login outputs a sign-in URL that can also be opened on another device; sign-in proceeds normally including two-factor authentication, and thus also works over SSH on a server without a desktop
• the session is stored in the operating system’s key store (Keychain, Credential Manager, libsecret) or, since version 0.6.0, in the password manager pass, which is more practical on servers without a desktop session
• after that: upload and download files, move them, send them to the trash, manage shares, invitations, and public links, and use Proton Photos; each with --json for machine-readable output

This means the password and TOTP key do not need to reside on the server. For backups and build artifacts, the CLI is therefore the better choice than Rclone today. Two limitations remain: the CLI cannot mount a file system and cannot create a mirror with deletions; it uploads and downloads but does not synchronize. Since version 0.9.0 of October 5, 2026, the command takeout for a complete local export has also been released.

Proton still classifies the SDK itself as not production-ready for third-party applications; release is planned for late 2026 to early 2027. The CLI is unaffected because Proton releases it itself.

The real gap: machine access

The heart of the problem lies one layer below the client or SDK: Proton has no machine access. No app password, no service account, no token with a limited scope. Every automation, whether a backup script, server mount, or CI job, must work with the account’s full credentials.

For comparison: with S3-compatible storage, access key pairs are standard, revocable, and can be limited to buckets or prefixes. Google and Microsoft support app passwords and service accounts. With Proton, however, it is all or nothing: anyone who wants to give a server access to one folder gives it the entire account.

With an end-to-end encrypted service, this is more difficult than with S3 because limited access would also have to mean limited key material. However, the CLI sessions show that Proton can handle such constructions. A session is already a derived, revocable credential, just one with the full scope of the account. An official “machine token for exactly this folder, read-only” would be the single biggest advance for server use, far ahead of any client.

Recommendation by use case

On the Linux desktop, you can wait for the announced client or use Rclone for now. On servers, the official CLI now handles backups and automation; for a mount, Rclone remains the only practical solution. But a working workaround will become a robust platform only when Proton offers limited machine access and an officially supported mount.

Change log

• October 25, 2026: Updated for Proton Drive CLI 0.9.0 from October 5, 2026, including the now-released takeout feature for a complete local export.