Proton Drive Is Hard to Migrate To or From. Blober Makes It Easy.

May 27, 2026

The Privacy-First Cloud Storage That’s Hard to Move Files Into

Proton Drive is one of the most privacy-respecting cloud storage services available. End-to-end PGP encryption. Swiss jurisdiction. Open-source clients. Zero-access architecture, so not even Proton can read your files. Over 100 million accounts trust it. If privacy is your priority, Proton Drive is a strong choice.

But there’s a catch: Proton built great sync clients, not transfer tools.

Their official apps sync a folder between your device and Proton Drive. That works perfectly when Proton Drive is your only cloud. The moment you need to move files from Google Drive, from Dropbox, from AWS S3, or to Proton Drive from another provider, you’re on your own. Download everything locally, then re-upload. For a few gigabytes, that’s fine. For 500 GB of photos across three Google accounts, it’s a weekend you don’t get back.

Where Proton Drive Is Officially Supported

Proton offers native clients on four platforms, plus web access:

Platform	Client	Sync	File Browser	Bulk Transfer From Other Clouds
Windows	✅ Desktop app	✅ Folder sync	✅ Via web	❌
macOS	✅ Desktop app	✅ Folder sync	✅ Via web	❌
iOS	✅ Mobile app	✅ Photo backup	✅ In-app	❌
Android	✅ Mobile app	✅ Photo backup	✅ In-app	❌
Linux	❌ No client	❌	✅ Web only	❌
Web	✅ Browser	❌	✅	❌

Notice the last column. Across every platform, on every client, there is no built-in way to transfer files from another cloud provider into Proton Drive. The official path is: download to your machine, then let the sync client pick it up. That means your files travel unencrypted across your local disk as an intermediary, and you need enough free local storage to hold everything in transit.

And if you’re on Linux, there is no desktop client at all. You get the web interface, which works but doesn’t support drag-and-drop bulk uploads from other services either.

What The Proton Client Does Well (And What It Doesn’t)

Credit where it’s due. The Proton Drive clients are well-built for their intended purpose:

What they do well:

Seamless folder sync between your device and Proton Drive
Automatic photo backup on mobile
End-to-end encryption handled transparently
Proton Docs and Sheets integration for collaboration
Multi-device access to the same encrypted vault

What they don’t do at all:

Move files between Proton Drive and another cloud provider
Migrate from Google Drive, Dropbox, OneDrive, or any S3-compatible storage
Browse or select files from another cloud as part of a transfer
Run a repeatable workflow (“every week, copy new photos from Dropbox to Proton Drive”)
Operate on Linux without a browser

This isn’t a criticism. Proton built a sync product, not a migration product. If you’ve committed to Proton’s privacy model and you have terabytes scattered across Google Drive, Dropbox, and a NAS, you need something else.

Thinking About rclone? Read This First

rclone is the go-to open-source CLI tool for cloud storage, supporting 70+ backends. It does have a Proton Drive backend. But before you rclone config your way in, there are things you should know.

rclone Classifies Proton Drive as Tier 4: Experimental

rclone organizes its backends into five support tiers. Proton Drive sits at Tier 4, Experimental: “Use with care; expect gaps/changes.” For comparison, AWS S3, Google Drive, and Dropbox are all Tier 1 (Core) or Tier 2 (Stable).

Tier 4 means:

Community-maintained, not by the rclone core team
The implementation is based on reverse-engineered APIs. There is no official Proton Drive API documentation.
Known gaps in functionality: modification times aren’t supported, caching doesn’t reflect changes from other clients, and draft conflicts from failed uploads can block subsequent uploads
The underlying library, Proton-API-Bridge, acknowledges there are “likely quite a few errors” due to the lack of official documentation

rclone Requires Your Proton Password

This is the big one. To configure rclone with Proton Drive, you must provide:

--protondrive-username    # Your Proton email
--protondrive-password    # Your actual Proton password
--protondrive-2fa         # Your 2FA code (if enabled)
--protondrive-mailbox-password  # Your mailbox password (if two-password mode)

Your password is stored in rclone’s config file. It’s “obscured” (base64-like), not encrypted. rclone’s own docs say obscuring is “not a secure way of encrypting these passwords as rclone can decrypt them” and exists only to prevent casual snooping. Anyone with read access to your rclone config has your Proton password.

For a service whose entire value proposition is zero-knowledge encryption, handing your master password to a third-party tool stored in a config file defeats the purpose. If that config leaks (via a backup, a dotfile sync, a misconfigured git repo), your entire Proton ecosystem (Mail, Calendar, VPN, Pass, Drive) is compromised.

rclone’s Proton Drive Limitations

Beyond the password issue:

No modification time support. Copied files lose their original timestamps.
Stale caching. rclone’s cache doesn’t update when other clients (web, mobile, desktop) modify files. Their docs explicitly warn: “if there are concurrent clients accessing the same mount point, then we might have a problem with caching the stale data”
Draft conflicts. A failed upload leaves a draft that blocks re-upload of the same file unless you set --protondrive-replace-existing-draft=true.
Encryption key requirement. Proton Drive encryption keys must have been already generated via a regular browser login before rclone can work. You can’t use rclone on a fresh Proton account without logging in through the browser first.

How Blober Handles Proton Drive Differently

Blober takes a fundamentally different approach to Proton Drive authentication and file transfer.

You Just Log In. Normally.

When you connect Proton Drive in Blober, a browser window opens to account.proton.me, which is Proton’s own login page. You sign in with your email, password, and 2FA exactly as you would in any browser. Your password never touches Blober. It stays inside the isolated browser session.

What Blober captures after you log in:

An encrypted session token (not your password)
A session-scoped cryptographic key derived by Proton’s own code (not your master password)
Session cookies that expire naturally

What Blober never sees:

Your password
Your 2FA secret
Your mailbox password
Your private PGP keys in cleartext

This is the same trust model as using Proton Drive in your browser. You log in through Proton’s interface; the session is handled by Proton’s code. Blober works with the session that results, not the credentials that create it.

Built On Proton’s Official SDK

Blober uses Proton’s official @protontech/drive-sdk for Proton Drive operations. That’s the same SDK Proton’s own web client is built on, so we’re not relying on a reverse-engineered API like the community libraries do.

What Blober Supports With Proton Drive

Operation	Supported	Details
Browse	✅	Navigate your full folder tree, including encrypted filenames
Download	✅	Streamed in 4 MiB blocks, 10 concurrent streams
Upload	✅	Streamed in 4 MiB blocks, 5 concurrent streams. Auto-creates folders
Delete	✅	Moves to Proton Trash (recoverable)
Metadata	✅	Filename, size, created/modified dates
Multiple accounts	✅	Each account gets an isolated session. Run transfers in parallel

What Blober Does That Proton’s Client Can’t

Transfer from any supported provider directly to Proton Drive. Google Drive, Dropbox, AWS S3, Azure Blob, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi, Rabata, GoPro Cloud, local disk. No intermediate downloads.
Transfer from Proton Drive to any other provider. Moving away from Proton? Moving a subset of files to cold storage on Backblaze? Blober handles it.
Selective file transfer. Browse your source, pick exactly the files you want, transfer only those. Not a full sync of everything.
Saved workflows. Set up “Dropbox to Proton Drive” once, run it whenever you want. The workflow remembers your source path, destination path, filters, and file naming templates.
Works on Linux. Blober runs on Windows, macOS, and Linux. Since Proton doesn’t ship a Linux desktop client, Blober is one of the few ways to get a desktop-native Proton Drive experience on Linux without using a browser.
Resumable transfers. If your session expires mid-transfer, Blober prompts you to re-authenticate and picks up where it left off. No files are lost or duplicated.

The Migration Scenario

Here’s the situation Blober is built for:

You’re on Google Drive or Dropbox. You’ve decided to move to Proton Drive for privacy. You have 200 GB of documents and photos spread across folders. Today, your options are:

Option A: Manual download and re-upload

Download 200 GB from Google Drive to your local machine (hours, needs free disk space)
Wait for Proton Drive sync client to upload it all (hours more, CPU-intensive due to encryption)
Repeat for Dropbox
Hope nothing failed silently

Option B: Google Takeout + manual upload

Request a Takeout archive (can take days)
Download the archive(s)
Extract, organize, upload to Proton Drive
Storage used: 3× (source cloud + local archive + Proton)

Option C: rclone

Give rclone your Google/Dropbox OAuth credentials AND your Proton password
Write the right command with the right flags (rclone copy gdrive: protondrive: --transfers 4 --checkers 8)
Hope the Tier 4 experimental backend doesn’t hit a draft conflict or caching issue mid-transfer
No resume on failure. Partial state requires manual cleanup.
Your Proton password is now in a config file on disk

Option D: Blober

Sign in to Google Drive (OAuth, no password stored) or Dropbox (OAuth)
Sign in to Proton Drive (browser login, no password stored)
Select the files you want
Start the transfer
Blober handles the full source-to-Proton flow as one workflow. Session-based auth means no passwords stored anywhere, and you can come back and re-run the same workflow later.

Blober vs rclone for Proton Drive: Side by Side

	Blober	rclone
Auth method	Browser login (Proton’s own login page)	Username + password in config file
Password stored?	No, session tokens only	Yes, obscured (not encrypted)
2FA support	Native, typed into the Proton login page	Must pass `--protondrive-2fa=CODE` per session
Support tier	Integrated with Proton’s official drive-sdk	Tier 4 Experimental via community library
Encryption	Proton’s SDK handles PGP key chain	Proton-API-Bridge (unofficial, self-described as “likely has errors”)
Modification times	Preserved from source metadata	Not supported by rclone’s Proton backend
Resume on failure	✅ Automatic	❌ Manual cleanup required
Concurrent clients	Session-isolated, no cache conflicts	Cache stale data warning in docs
GUI	✅ Native desktop app	CLI only (experimental web GUI exists)
Linux support	✅ Native desktop app	✅ CLI
Cross-provider transfer	✅ Direct stream between providers	✅ Via `rclone copy source: dest:`
Multiple Proton accounts	✅ Isolated sessions	Requires separate config remotes

Who This Is For

You should use Blober with Proton Drive if:

You’re migrating into Proton Drive from Google Drive, Dropbox, or another cloud
You’re moving out of Proton Drive to another provider, or shifting a subset to cold storage
You’re on Linux and want a desktop-native way to manage Proton Drive files
You don’t want to hand your Proton password to a third-party tool
You want a repeatable workflow, not a one-off command you’ll forget

You might still want rclone if:

You need scriptable cron-based automation and are comfortable with the experimental status
You’re already deep in the rclone ecosystem and accept the password trade-off
You need mount/FUSE support (rclone can mount Proton Drive as a filesystem; Blober cannot)

The Honest Take

Proton Drive is a genuine privacy-first storage service. It’s not a marketing wrapper around server-side encryption. It’s real end-to-end PGP with zero-knowledge architecture. The problem is that privacy and interoperability are often at odds. Proton’s encryption model makes it harder for third-party tools to integrate, which is partly why rclone’s support is Tier 4 and why no public API exists.

Blober works around this by authenticating the way a human does, through Proton’s own login page, and using Proton’s own SDK for Drive operations. It’s not a hack or a reverse-engineered API client. It’s the same trust boundary you already accept when you open drive.proton.me in your browser.

If you have files in other clouds and you want them in Proton Drive (or files in Proton Drive that you want elsewhere) without storing your Proton password in a config file, and without writing CLI commands against an experimental backend: that’s what Blober is for.