Proton use case

What is the problem you are having with rclone?

Hello, I want to explain my use case and double-check here if rclone is the right solution for me.
I am coming from Nextcloud, where my cloud files would be synced bidirectionnally in the background. I have switched to Proton, for which Rclone seems to be the best Linux solution (I am on Linux, and Proton has no official client for this plateform).

I understand that I won't have the possibility to have my files synced on the fly, and I don't mind at all. My ideal setup would be to have a "Push" (sync from local to remote) and a "Pull" (sync from remote to local) button/shortcut/command to execute. I would run it pretty regularly (several times a day), and would expect it to be fairly quick (basically just the download/upload time).

My remote is a 250GB bunch of massive files as well as loooooads of small files.

But I've started to do some tests with sync in pull mode (from remote to local), and there seems to be a check step that not only takes ages (I've stopped it after 35min) but also takes a lot of download (even just the dry-run, it looks like a lot of things are downloaded?).

So my question is: Is my use case compatible with rclone? The use case being "I want to trigger pull sync and push sync on a large cloud files group (250GB) several times a day, and have a small execution time (upload/download time only) and no unnecessary download.

Run the command 'rclone version' and share the full output of the command.

rclone v1.66.0-beta.7750.8c69455c3
- os/version: fedora 39 (64 bit)
- os/kernel: 6.7.7-200.fc39.x86_64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.22.1
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Proton Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone sync Proton:/ /path/to/Cloud/ --progress

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

type = protondrive
password = XXX
username =
client_uid = XXX
client_access_token = XXX
client_refresh_token = XXX
client_salted_key_pass = XXX

Proton remote is still in beta.

It is known to be slow and you can see on this forum multiple threads about various issues. I would not use it for anything important.


I have a daily separated backup, so I'm not too worried about accidents, worst comes to worst, I lose 24h of data, no big deal.

My only plan B so far is to switch to Windows... After 20 years on Linux, I'm not so keen :smiley: So I'm happy to experiment and dig with rclone.

I have searched the forum a bit, especially looking for information about why the remote>local sync would take some much download traffic only for "checking" (and why so much time, even if that is less of an issue to me), but could not find anything. I'm not familiar with Rclone, maybe I'm not using the right keywords?

In your particular case the problem is not rclone but proton remote. Obviously not all remotes are created equal:)

For example for checking files many support recursive listing when single API call can retrieve thousands of items. But not proton. Not difficult to guess what practical consequences are when you want to check many objects.

Here you are various features summary and remotes' comparison.

In addition proton remote is a new kid on the block with its author recently in rather quiet mode - so no progress is made in fixing/improving things. Hopefully somebody will show some initiative here - but it is open source project so no guarantees.

It does not help that Proton does not provide official API - such uncooperative providers often only "just work" without any optimisation and extra features possible. Send an email to them and lobby for more open approach:)

Oookay, thanks for the enlightment :slight_smile: . I now understand how my issue is to do with the remote implementation, which is limited by Proton's opacity.

I guess it's time to start looking for a plan A.b, and send an email to Proton.

Thank you for your time!

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.