Files synced but not visible in Google Drive web UI

I’ve uploaded files using rclone to a Google Drive. I can see correct contents on the drive using rclone ls but when viewing the drive with the web UI (Chrome) the contents aren’t visible. (Also, rclone ls reveals only what it uploaded, none of the other existing content on the drive.)

My goal is to be able to view the synced contents using the web UI.

Thanks in advance if someone can point me in the right direction.


  • The upload was performed using rclone copy
  • Authentication is done with a Service Account
  • Specifying a root_folder_id for a directory I made in the web UI caused a 404 when trying to upload to it.
  • It’s almost like the files are being uploaded to another drive (I checked all my other accounts to see if the files were going somewhere else. They aren’t.)
  • The Google account I’m using is part of a G Suite account.

System info:

  • Ubuntu 16.04 (64-bit)
  • rclone v1.39-235-g89748feaβ
  • os/arch: linux/amd64
  • go version: go1.10

This means by default the data will go into an area only accessible via the service account.

I suspect you want the latest beta and to use the --drive-impersonate user flag if you want to get them into a specific users folder.

1 Like

Thanks for the fast response. Here’s what I’ve found so far…

Using the --drive-impersonate flag gets this response from Google Drive:

Response: {
  "error" : "unauthorized_client",
  "error_description" : "Client is unauthorized to retrieve access tokens using this method."

I tried giving the service account appropriate domain-wide authority to go into the drives of users in that domain, but kept getting the same error.

I’m working on this from a different angle now. I’m attempting to log in using regular Client ID + Client Secret credentials, no service account. I’m running into redirect uri mismatch problems right now.

I should mention that I’m setting up rclone on a remote/headless machine.

  1. When setting up the remote in rclone config I enter the Client ID and Client Secret.
  2. In my browser, I add as an authorized redirect URI, as rlcone asked me to.
  3. In rclone, I type n since I’m on a headless machine and rclone gives me a link to copy/paste into my browser. However, this link’s redirect_uri is of the urn:xxxx:xx:oauth:2.0:xxx variety. This produces a 400 error when I go to the link in my browser. (Google’s message: “The redirect URI in the request, [redacted], can only be used by a Client ID for native application. It is not allowed for the WEB client type.”)
  4. Just to see what would happen, I replaced the value of the redirect_uri parameter with http%3A%2F%2F127.0.0.1%3A53682 (which us URL-encoded Using this in the link takes me to Google Account login screen and allows me to authorize the app for access to Google Drive.
  5. Upon clicking Allow, I get redirected to with two parameters: state and code. I tried copy-pasting the code value into rclone but it then responds with “Failed to configure token: failed to get token: oauth2: cannot fetch token: 400 Bad Request” Response: { "error" : "redirect_uri_mismatch" }.

That’s where I am now. Maybe I’m going about this all wrong but this is the closest I’ve come to getting this working.

Thanks again for your help.

I’m afraid I don’t know a great deal about service accounts. However there is lots of useful info in this issue!

You should find it easier to use one of these two methods.

Success! I’ll document thoroughly what I did in this post for others in the future. I hope it saves someone else a lot of time.

Setting up a Service Account which can act on behalf of any user in a G Suite domain

This post explains how I was able to set up a service account within a G Suite domain which can use the --drive-impersonate flag to enter the Google Drive of any user on that domain. Four key takeaways:

  • Domain-wide Delegation must be enabled for the service account
  • Enabling DwD should create a Client ID for that service account
  • That Client ID must be authorized by the admin of the G Suite domain to access drives of users in that domain
  • All of this should be done using the account which administers the G Suite domain. (This may not be strictly necessary but for me it seems to have been crucial.)

Setting things up in the Google APIs console

  1. Go to and log in as the administrator of the G Suite domain.
  2. Create a project if you haven’t already. Be sure that when you create the project, your domain is selected as the organization, not “No organization.” Be sure to enable the Google Drive API.
  3. Go to Credentials and set up a new Service Account.
  4. Create a key for this service account. This should automatically download a JSON file with the credentials.
  5. Enable Domain-wide Delegation for this service account. (Click on the ‘edit’ item in that service account’s menu. You’ll get a dialog that lets you check the ‘Enable G Suite Domain-Wide Delegation’ checkbox.)
  6. Enabling DwD creates a Service account client. When you look at all credentials, you will see “Client for [service account]” has been added. That client will have a Client ID. Copy it to your clipboard or leave this tab open.

G Suite Admin

  1. Now we have to authorize the Client ID of the “Client for [service account]” on your G Suite domain. Go to (still logged in to the administrative account).
  2. Click on Security > Advanced settings > Manage API client access
  3. In the row for adding a new client, paste the Client ID of the service account client. In the API Scopes field, you can enter the appropriate scopes. For rclone it is most likely


  1. Run rclone config. Set up your remote without entering a Client ID or Client Secret, just the JSON file with the credentials for the service account.

You should now be able to use rclone using the --drive-impersonate flag to act as if you were any user on that domain. For example:

rclone ls --drive-impersonate remote:


I tried the above previously, but using a service account which was created by a user other than the G Suite administrator. That service account was not allowed access, even when approved by the administrator. I don’t know if others will have this problem as well, maybe it’s not necessary to use a service account created by the admin, but in my case it definitely seemed to be what finally made it work.