rclone: no backendGoPro Cloud
There is no gopro: remote to configure and no public API to write one against. Blober signs in to GoPro Cloud and moves the library at full resolution, without the 25-file download batches the web portal uses.
Blober vs rclone
Blober signs in to GoPro Cloud, writes into iCloud Photos, reads the Google Photos library you already have, and builds Proton Photos tiles on your machine. rclone is a fine tool for files between mainstream clouds. This page shows which one fits which job.
Blober signs in to the providers rclone has no backend for, writes into the libraries rclone can only read, and keeps your password out of a config file.
Two paragraphs and a table. The rest of the page is the evidence.
Blober is the transfer app for the accounts rclone cannot sign in to: GoPro Cloud, iCloud Photos with write access, a Google Photos library that already exists, and Proton Photos with tiles built on your machine. It covers the mainstream providers too, 19 in all, plus any S3-compatible endpoint.
rclone is the better pick for a one-off migration between providers it already supports, a scheduled job on a server, or anything that needs its 70+ backends. It is free and open source, and this page says so.
The job this page is about, tried in rclone:
$ rclone copy gopro:100GOPRO b2:footage/2026
2026/09/22 10:14:03 ERROR : Failed to create file system
for "gopro:100GOPRO": didn't find section in
config filerclone has no GoPro backend, so no flag reaches one.
| If the job is | Use |
|---|---|
| GoPro Cloud, iCloud Photos, Proton Photos, or a Google Photos library that already exists | Bloberrclone has no backend for these, or a read-only one |
| Files between Drive, Dropbox, OneDrive, S3 and the rest | Eitherboth handle mainstream providers |
| Any other S3-compatible endpoint | EitherBlober reaches it through S3 compatibility |
| A one-off, scripted, scheduled migration | rclonefree, headless, 70+ backends |
| A saved workflow you rerun on the desktop | Bloberpick it once, click to run again, resume where it stopped |
Each of these is a limit in rclone's own documentation or protocol, not a matter of opinion: a backend that does not exist, a service it marks read-only, an API that stopped serving other people's photos, and a derivative only the key holder can make.
rclone: no backendThere is no gopro: remote to configure and no public API to write one against. Blober signs in to GoPro Cloud and moves the library at full resolution, without the 25-file download batches the web portal uses.
rclone: read-onlyrclone added an iCloud backend that can read the Photos library. Its documentation states the service is read-only and that upload, delete, rename and move are not supported. Blober uploads into the library and keeps the capture date.
rclone: files onlyProton is end-to-end encrypted, so the tile has to be built on your machine before the upload. Blober generates image tiles, a video poster and audio album art as it goes.
rclone: uploads onlySince 31 March 2025 rclone can only download the photos it uploaded itself, so a library that predates your rclone use is out of reach without Takeout. Blober reads the whole library, with no Takeout zip and no Google Cloud project to register.
Google’s API hands back a compressed copy with the EXIF stripped, and rclone’s answer is a separate proxy that drives a headless browser on your machine. Blober pulls the original bytes and keeps the capture date and the EXIF with them.
An iCloud remote is set up with your Apple ID password and a 2FA code, and a Proton remote with your Proton password and mailbox password; both sit in rclone.conf, and the iCloud trust token needs renewing every 30 days. Blober signs in on the provider’s own page and stores no provider password at all.
A thumbnail is the one derivative a transfer tool has to make itself, because on an encrypted provider nobody else can.
no tile in the record
rcloneImages get a small tile and a larger preview, encoded from the pixels the adapter already holds, with EXIF rotation applied so a portrait photo is not sideways.
Video gets a poster frame taken from the clip, with the container's own rotation applied. Audio gets its embedded album art.
The work only happens when the provider cannot do it itself. On an upload to a provider that builds its own derivatives, nothing is generated and no native module is even loaded. A file that cannot be decoded still uploads, because a missing thumbnail should never fail a transfer.
Where rclone can do something with a caveat, the table says Partly instead of hiding it. Skim to the heading that answers your question and stop there.
| Capability | Blober | rclone |
|---|---|---|
| Providers | ||
| GoPro Cloud | BloberNo other general-purpose transfer tool has itsupported | rcloneNo backendnot supported |
| iCloud Drive | Blobersupported | rcloneSince v1.69supported |
| iCloud Photos, reading | Blobersupported | rclonesupported |
| iCloud Photos, writing | Blobersupported | rcloneRead-only, in its own docsnot supported |
| Proton Drive files | Blobersupported | rcloneBeta, on a third-party bridgepartially supported |
| Proton Photos | BloberUploaded with client-built tilessupported | rclonenot supported |
| Google Photos: the library that already exists | Blobersupported | rcloneOnly what it uploaded, since 31 March 2025not supported |
| Google Photos: full-resolution originals | Blobersupported | rcloneNeeds the gphotosdl headless-browser proxypartially supported |
| Google Photos with nothing of your own to register | BloberNo Google Cloud projectsupported | rcloneYour own client ID, as the shared one retires in 2026not supported |
| Drive, Dropbox, OneDrive, Box, the S3 family | Blobersupported | rclonesupported |
| Any S3-compatible endpoint | Blobersupported | rclonesupported |
| Backend count | Blober19 in the app, plus any S3-compatible endpointpartially supported | rcloneOver 70supported |
| Running a transfer | ||
| Desktop app | Blobersupported | rcloneThird-party GUIs existnot supported |
| Cloud-to-cloud, data path direct | Blobersupported | rclonesupported |
| Local drives, SD cards and NAS | Blobersupported | rclonesupported |
| Saved, reusable workflows | Blobersupported | rcloneYou maintain the scriptnot supported |
| Resume an interrupted run from stored state | Blobersupported | rcloneRe-runs and re-checkspartially supported |
| Per-file history after the run | Blobersupported | rcloneLog filepartially supported |
| Progress: files handled and bytes moved | Blobersupported | rclone--progress and --statssupported |
| Flags to remember per job | BloberNonesupported | rcloneEvery jobnot supported |
| Deduplication as a destination setting | Blobersupported | rcloneFlagspartially supported |
| Path templates built from file metadata | Blobersupported | rcloneScript itnot supported |
| Filters and globs | Blobersupported | rclonesupported |
| Keeps the machine awake during a long run | Blobersupported | rcloneWrap it in caffeinate or systemd-inhibitnot supported |
| Media and derivatives | ||
| Thumbnails generated during transfer | BloberImages, video posters, audio artsupported | rclonenot supported |
| Capture date preserved into photos | Blobersupported | rcloneWhere the API allows, and it cannot write to iCloud Photospartially supported |
| Fills the tile fields when the provider cannot | Blobersupported | rclonenot supported |
| Credentials and setup | ||
| Sign in through the provider’s own web page | Blobersupported | rcloneBrowser OAuth, or SRP with 2FA for iCloudsupported |
| Your Apple ID and Proton passwords stay yours | BloberSession cookies onlysupported | rcloneBoth go in rclone.confnot supported |
| Nothing to keep in sync by hand | BloberNo config filesupported | rclonerclone.conf, one per machinenot supported |
| Several accounts per provider | Blobersupported | rcloneOne remote eachsupported |
| Everything else | ||
| Mount cloud storage as a local drive | Blobernot supported | rclonesupported |
| Client-side encryption (crypt) | BloberPlannednot supported | rclonesupported |
| Two-way sync | BloberPlannednot supported | rclonesupported |
| Scheduling | Blobernot supported | rclonecron or the OSsupported |
| Headless, for a server | Blobernot supported | rclonesupported |
| Run from a script or CI | Blobernot supported | rclonesupported |
| Open source | Blobernot supported | rcloneMITsupported |
| Price | BloberOne-time licencepartially supported | rcloneFreesupported |
| Support | BloberProduct supportsupported | rcloneCommunitypartially supported |
Six jobs rclone still does better. If one of them is your whole job, you already have the right tool and it is free.
Plenty of people run both: rclone on the server, on a schedule, against whichever remote needs it, and Blober on the desktop for the media libraries and the providers with no backend.
No. Blober does not use rclone, wrap it or ship it. It is a separate transfer engine with its own adapters, which is how it reaches providers rclone has no backend for and why it can write into iCloud Photos and read a Google Photos library that predates it. A GUI over rclone inherits exactly what rclone can and cannot do.
It can move files in iCloud Drive, since v1.69. It cannot write to iCloud Photos: rclone’s own page states that the service is read-only and that upload, delete, rename and move are not supported. Blober does both, so a camera roll, an old phone backup or a client delivery can go into the Photos timeline rather than sit next to it.
Not any more. Since 31 March 2025 rclone can only download the photos it uploaded itself, so a library that predates your rclone use needs Takeout. Because its shared client ID is being retired during 2026 it also wants a Google Cloud project of your own, and full-resolution originals want the separate gphotosdl proxy. Blober reads the library directly.
For iCloud, yes: a remote is configured with your Apple ID password and a 2FA code, and the trust token in rclone.conf is renewed every 30 days. A Proton remote is configured the same way, with your Proton password and mailbox password. Blober opens the provider’s own sign-in page in a window, so no provider password is written to disk at all.
It matters in one place, which is why it is one section of this page and not its headline: the end-to-end encrypted providers. Proton never sees your pixels, so it cannot build the tile, and an upload without one lands as a grey square in the timeline. Blober makes the image tile, the video poster and the audio cover on your machine as it uploads. Everywhere else the provider builds its own, and Blober does no work at all.
No. Transfers run on your machine over your own connection, straight to the provider. There is no middleman holding your credentials or a copy of your data, which is a property it shares with rclone.
When you need a provider Blober does not ship, an encrypted remote, a two-way sync, a mount, or something that runs headless on a schedule. rclone does those jobs well and costs nothing, and plenty of people run both: rclone on the server, Blober for the media libraries and the proprietary providers.
A one-time licence with the current launch discount. No subscription, no per-transfer fee, and updates are included.
The same tradeoffs at length, and the guides for the providers this page keeps mentioning.
Pick the accounts, tick what moves, and run it. Sign-in happens on each provider's own page, and the job stays saved as a workflow you can rerun.
Get Blober for desktopmacOS · Windows · Linux