Hi, new to RcloneView. I think I’ve set up Google Photos and Drive access correctly (at least from the tutorials) but I get little to no functionality. Drive will work, but takes extremely long just to list the files in a folder. Photos copy will not work at all - the job says “Waiting for available workers” and then eventually gets marked completed with no files or folders actually being transferred. How do I troubleshoot what’s wrong? Thanks!
Welcome to the community, PlacidFury! 
You’ve actually run into two separate issues here — one is a tuning problem, the other is a hard limitation Google imposed last year. Let me split them.
- Google Drive is slow to list folders
This is almost always the shared client ID / rate-limit issue, and it’s fixable.
By default, RcloneView (via rclone) talks to Google Drive using rclone’s built-in API client ID, which is shared by every rclone user in the world. Google enforces a per-client-ID rate limit, so during busy periods your listing requests get throttled and folders crawl. Drive is also just inherently rate-limited — large individual files fly at 100s of MiB/s, but lots of small files/entries get capped.
Two changes make a big difference:
- Create your own Google API client ID — this is the single biggest fix. It gives you your own private quota instead of sharing rclone’s. It takes ~5 minutes in the Google API Console (enable the Google Drive API, create an OAuth client ID, paste the ID + secret into the remote’s config). Full steps: Google drive
- Enable --fast-list for Drive. It combines many folder-listing calls into single API requests. rclone’s own benchmark on a large folder (10,600 dirs / 39,000 files) went from 22 minutes → 58 seconds. In RcloneView you can add --fast-list as a global rclone flag in Settings → Advanced / rclone flags. (Trade-off: uses a bit more memory, which is fine on desktop.)
If it’s still sluggish after that, you can gently pace requests with --drive-pacer-min-sleep 100ms and --drive-pacer-burst 100, but honestly the own-client-ID + fast-list combo solves it 95% of the time.
- Google Photos “completes” but transfers nothing
This one isn’t a misconfiguration on your end — it’s a Google policy change, and the “job completes with 0 files” symptom is the classic tell.
As of March 31, 2025, the Google Photos API only lets apps see and download photos that the app itself uploaded. Apps can no longer read or back up your existing library. rclone (and therefore RcloneView) had to adopt this restriction. See Google’s own notice: Updates to the Google Photos APIs | Google for Developers and rclone’s note: Google Photos
So when your copy job runs, the API returns an empty/permission-limited result for your existing photos → the worker has nothing to transfer → the job is marked completed with 0 files. If your auth token was created before this change, you may instead be getting a silent 403 PERMISSION_DENIED on the removed scopes.
What to do:
-
Reconnect / re-authorize the Google Photos remote. In RcloneView, open the remote’s settings and re-run the OAuth login (this is the equivalent of rclone config reconnect remote:). Make sure you’re on a recent RcloneView build (rclone core v1.70+). Old tokens with the removed scopes will otherwise keep failing.
-
Check the job log for the exact error — look for 403 PERMISSION_DENIED or User rate limit exceeded. That confirms which of the two cases you’re in. If you can paste that log line here, I can pin it down for you. (We also have a walkthrough here: Fix Google Photos Sync Errors — How to Resolve with RcloneView | RcloneView Support Center)
-
Set expectations on what’s possible now:
- You can upload photos/videos to Google Photos, and download only what rclone/RcloneView itself uploaded.
- You cannot back up or re-download your existing Google Photos library through the API anymore — no third-party tool can, it’s an API-level lock.
- Even for photos the API does return, downloads come without original resolution and with GPS/EXIF stripped. If your goal is a true archive of your existing library, Google Takeout is the reliable route. (For full-resolution advanced gphotosdl proxy:Google Photos)
- Browsing tip: the Photos remote is laid out as media/all, media/bus album/…. Use by-month for syncing and avoid by-day — it’s veryslow.
TL;DR: Drive is slow because you’re on the shared API client — make n on --fast-list. Photos “does nothing” because since March 2025Google only lets apps touch photos they uploaded themselves; reconnect the remote to clear stale-token errors, and use Google Takeout if you’re trying to back up an existing library.
If you grab that Photos job log line, post it and we’ll confirm exac
Thanks for the thorough reply! Bummer that Google did that - I had no idea. The main thing I was wanting this for was Photos backup, so it looks like it’s going to be a no-go then.
Scratch that - I did the Drive instructions and it works beautifully now. As far as photos go, while I’d prefer Google Photos worked, I may try OneDrive instead as I also have my photos backing up there. It would capture the vast majority of what I’m trying to backup to my file server.
Hi - I know I’m straying from my own topic, but I was looking at the OneDrive instructions on the same Rclone page you sent for the Google Drive setup. The link it has for portal.azure.com for setting up OneDrive Personal didn’t give me the opportunity to setup an account - it simply said I can’t do it because it’s deprecated. Am I missing something?