Google Drive and Google Photos users - ACTION REQUIRED

Annoucements
1

Hi All

Rclone's internal client-ID will stop working in 2026 - please make your own

We recently received a notification from Google that Google will start charging for API requests on rclone's built in default client-ID for Google Drive and Google Photos. The timescale for this is "Later in 2026, following 90 days of notice".

Since we are many hundreds of times over the free quota this would mean that the rclone project would have to start spending lots of money on quota requests. We don't know exactly how much because Google haven't released the pricing yet, but millions of dollars per year seems likely.

What we are doing

  • Add a warning to rclone (in the next point release) if you are using the default client-ID something like

NOTICE: This remote uses rclone's shared Google Drive client_id, which is
being retired and will stop working during 2026. Create your own client_id
to avoid interruption: https://rclone.org/drive/#making-your-own-client-id

  • Post an update when we know when exactly the 90 days starts
  • Disable the default client-ID before the end of the 90 day period
  • Remove the default client-ID at the next release

What you need to do

  1. Check if you are using the default Google client-ID. You can do this using rclone config show YourDriveOrPhotosRemoteName:. If you have set client_id and client_secret already you have nothing to do. If they are blank or missing then follow the next steps. If you are using a service account you don't need to change anything.
  2. Stop any rclone processes (eg rclone mount) using YourDriveOrPhotosRemoteName:
  3. Make your own client_id and client_secret following the guide in the google drive backend docs and add it to your config.
  4. In step 11 run rclone config reconnect YourDriveOrPhotosRemoteName: and answer "Y" when it asks "Already have a token - refresh?". This part is important otherwise rclone won't actually use your new client_id/client_secret.
  5. Repeat for all your google drive and google photos remotes. You only need to make one client_id/client_secret - you can add this to all your remotes but you must also run rclone config reconnect on each of them.

We are still talking to Google about this but we don't think their plan will change other than the timescales.

Happy rcloning and sorry for the inconvenience

Nick

PS Feedback appreciated.

3 Likes
ClientID automation : winter is coming = deadline closing in
Rclone wrapper tool for Google Drive
Rclone Release v1.75.0
ClientID automation : winter is coming = deadline closing in
3

Hi,

I will be available and happy to assist those who get stuck creating their client ID.

1 Like
4

Should have been done ages ago! Glad I had mine setup this way to start with!

Kudos to you for letting us mooch off of yours for years!

5

Well, I wanted to make it easy for users to get going... You are right though @Turner it has been obvious for a while that something like this was coming due to the ever increasing difficulty of getting your client id verified. It took 3 months and $600 last time!

6

Thanks for the update and explanation. It's good to know this is a Google API policy change rather than an rclone issue. The migration guidance and timeline should help users prepare before access is affected.

1 Like
7

Always used mine, as using a shared one seemed a recipe for disaster.

I think rclone is handling this in the best possible way.

2 Likes
8

I was looking at this for the tasks.org android and desktop app. The author there said it would cost him between US$15k - $35k. Seems they have been treating you favourably. I suspect they will go on to charge everyone for API access at some point.

1 Like
9

I just stumbled on this thread while writing some scripts to help my with syncing my large Google Drive.

There is a class of users for whom "create your own client ID" is not possible, and I haven't seen it mentioned in this thread:

Accounts enrolled in Google's Advanced Protection Program (APP)

I'm one of them, and I tested this thoroughly today before posting.

Here's my experience. Personal Cloud project, Drive API enabled, OAuth consent screen configured, Desktop-app client, me as the app's sole author and user:

  • scope drive.readonly, publishing status "In production" -> Error 400: policy_enforced, "Access blocked: app is not approved by Advanced Protection"
  • same scope, status "Testing", my own address added as test user, scopes declared on the consent screen -> identical error
  • scope drive.file (non-sensitive tier) -> consent succeeds, token works

So APP blocks any unverified app requesting a sensitive or restricted scope.

It does not matter that I registered the client, that I'm the developer, or what the publishing status is. drive.file passes but is useless for sync. The token sees zero existing files (I checked: lsf and backend query return nothing until the app creates files or you pick them one by one in Google's Picker).

Before anyone suggests the usual fixes:

  • Verification is not the gate. Leaving the bureaucracy aside, client-ids that work under APP (rclone's, Thunderbird desktop's) belong to verified apps. But verification alone doesn't put you on the APP allowlist. Thunderbird for Android - same organization, same Gmail scope - has been blocked since 2024 (thunderbird/thunderbird-android#8256). The allowlist appears to be per-client-id, hand-curated, and unreachable. Even Google's own Apps Script CLI is blocked (google/clasp#946).
  • Service accounts: Tried but cannot see Shared-with-me, and need every folder shared to them by hand. Clumsy and not a proper mirror.
  • Workspace migration: Admin-trusted client IDs supposedly work under APP (not tested today to be honest), but moving a consumer account to Workspace orphans every Shared-with-me grant tied to the @gmailgmail identity, so it's not a reasonable workaround for most people, including myself.
  • Drive for Desktop: no Linux, no headless, no Shared-with-me, gdocs become stubs. Wholly inferior to rsync (which is why we are here).
  • App passwords: revoked under APP, and never covered the Drive API anyway.

Which leaves the uncomfortable conclusion: rclone's built-in client ID currently works for users like me because it's on Google's internal allowlist. When it's retired, APP users go from "works fine" to "no path at all".

If there is an open line to Google about this change: could this user class be put on the table? The fix on Google's side is small and already exists for Workspace - admins can mark a client ID as trusted. A consumer-account equivalent ("I am the author of this app, I trust it") would resolve it. Failing that, some successor to the allowlisted shared credential.

And if anyone here with Advanced Protection has successfully moved to their own client ID, I'd genuinely like to hear how, because I just spent a whole day on it and could not find any success stories elsewhere.

1 Like
How to authorize rclone for Google Drive without disabling Advanced Protection Program?
10

Thanks for the report @ptu that is very useful feedback. I will send this to Google as a possible gotcha for the migration as I have an open ticket with them where we've been discussing the change.

2 Likes
11

Would like to add a note on the implications re privacy of personal clientIDs, a fair warning.

A personal clientID "links" the account of the clientID to any other account accessing a remote. So, while google has user related information ("knowledge" of who accesses an account), the common clientID did not allow by its only use to establish links between remote accounts. Using a personal clientID from other person with your remote brings this linkage risk (not saying that google will link, but would have the means).

It them becomes essential to explain users that they should not use other person clientID and that if they have several remotes (limiting terms applying), if privacy concerns are important, they should create a per remote clientID ...

Not that the rclone team wished this to happen but this is how it goes

12

Just in case it might be of interest, I was shared the steps for personal ClientID creation in Spanish.

Paste 0_hK0bBdtLKq · NullPaste pass ClientID

Enjoy if that is your language, might be it can be incorporated somewhere in the website.

Later adding

Seems there are some changes for creation of ClientID - see Can't configure Google Drive client ID

Step 5 in Google drive

If you already configured an "Oauth Consent Screen", then skip to the next step; if not, click on "CONFIGURE CONSENT SCREEN" button (near the top right corner of the right panel), then click "Get started". On the next screen, enter an "Application name" ("rclone" is OK); enter "User Support Email" (your own email is OK); Next, under Audience select "External". Next enter your own contact information, agree to terms and click "Create". You should now see rclone (or your project name) in a box in the top left of the screen.

To be added a new step: click on branding, then include url for homepage and privacy policy (probably best to add also Terms of service), then add domain under authorized domains, save.

(some suggestions in Can't configure Google Drive client ID)

On another note,

Fair warning, google states: "Inactive OAuth clients are subject to deletion if they are not used for 6 months." Subject to deletion does not means automatic deletion, but I would use the client at least once every 6 months less a day ...

13

Have some doubts.

When created a private/personal ClientIDs following the guide, website warned that it might be needing verification as it does include sensible scopes ... What we can expect about this.... Has past experience showed that unverified ClientIDs become void after certain time lapse or usage?

Is adding a logo making unverified ClientIDs having shorter lifespans?

Are unverified ClientIDs having limits in terms of DRIVE remotes (accounts) being used in? I was unable to understand how the 100 users limit kicks in... - Later edit - looks clear that unverified ClientIDs (apps) have a 100 user limit cap - check here Unverified apps - Google Cloud Platform Console Help . User respecting Google account limits should be impacted. Some people might like to have a clientID per drive account though.

14

I use rclone on my Fedora 44 system to back up files to my google drive. A discussion on the fedora-users email list sent me to this post. I followed the instructions in the guide noted in step 3 above. I've followed the steps in that guide. I get to step 9 there and go to Audience but the Publish App button is gray. There is a notice at the top of the Audience page that says my OAuth configuration is incomplete and it wants me to go to the Branding page to finish configuration. I go there but I am not sure what information to enter in to the form found on that page. Any help or suggestions would be greatly appreciated. Thanks so much.

15

I had the same problem: Can't configure Google Drive client ID

It seems it now requires Homepage URL and Privacy policy. Not sure what's the proper solution yet, if there is one.

16

Hmm. I actually have a domain running on my home server. It's dennett.org. If you go there all you'll see in my genealogy project. However, I could easily make up a couple of text files for a privacy policy and TOS and add those links to the Branding page. Is that really all I need to do?

17

Son of a gun. That's what I did and I could complete the setup. The I ran rclone config and supplied the client id and secret. Then I ran my rclone backup script and it worked. Appeared to be much faster, too. I actually have 3 google account I use rclone with. One is for testing and the other two are for backups of important files. (I also back up nightly t a couple of local external drives.) All 3 scripts completed successfully after reconfiguration.

18

Anyone having problems with the registration of personal ClientID please read Google Drive and Google Photos users - ACTION REQUIRED - #12 by caspertone2003

Explanation and workaround provided