A token.json file is already has been saved. That's it! Check the root folder of your server. If this shows you this app isn't verified then skip this by > advance > Go to Quickstart(unsafe). Select your account if you have multiple accounts. This will provide us a URL to get permission from google. * Įnter fullscreen mode Exit fullscreen mode * execute the given callback with the authorized OAuth2 client.
#GOOGLE DRIVE SCOPE V3 UPDATE#
It seems to me that by running the "move" command through "rc", the rclone instance doing the mount has all the information it needs to update the directory cache correctly.* Get and store new token after prompting for user authorization, and then This behaviour is rather annoying if you're using an -like setup with mergerfs and moving a dir from "local" to "remote". I would like to run "rclone mount crypt0:" with the "-poll-interval=0" option, but if I do that and then run something like "rclone rc sync/move /tmp/dir crypt0:" against the rclone instance doing the mount then the contents of /tmp/dir disappears until I explicitly run "rclone rc vfs/refresh". Does this seem like a reasonable approach? Any potential issues with caching of crypt0 and concurrent restic access to drive0:84260d93-85b9-4b15-9ae8-49537b99130b?Īlso, one other thing. Where drive0: contains $ rclone lsf drive0: $ rclone lsd drive: -drive-trashed-only=true Rclone shows the folder as both trash and non-trash! Surely this must be a bug in rclone? $ rclone lsd drive: -drive-trashed-only=false If I create a folder, say test7, via the web interface, and use this config: (The Empty trash button on the web interface may remove things that are not actually shown in the Trash folder on the web interface! At least with rclone you can fiddle with the root_folder_id and trashed_only options and SEE both types of trash.) I actually think this behaviour is a bit dangerous, but, of course, out of your hands. Note that if you don’t want trashed files you can put -drive-use-trash=false or use_trash = false in the config.Īnyway, with this config (and as API scopes): Ĭleanup now works – which is to say, it works like the Empty trash button on the web interface in that it removes both app-specific and non-app-specific trash. $ rclone delete drive:file -drive-trashed-only -drive-use-trash=false Things work as expected: $ rclone -v -drive-impersonate ls drive:Īnyway, I’ve done a bit more testing, with the latest beta and this config (and as API scope): Īny idea whether this is another scope-related issue? Or something else entirely? $ rclone about drive:Ĩ 22:06:01 ERROR : Attempt 1/3 failed with 0 errors and: googleapi: Error 403: Insufficient Permission, insufficientPermissionsĨ 22:06:01 ERROR : Attempt 2/3 failed with 0 errors and: googleapi: Error 403: Insufficient Permission, insufficientPermissionsĨ 22:06:01 ERROR : Attempt 3/3 failed with 0 errors and: googleapi: Error 403: Insufficient Permission, insufficientPermissionsĨ 22:06:01 Failed to cleanup: googleapi: Error 403: Insufficient Permission, insufficientPermissions
If, on the other hand, I put in the “One or More API Scopes” field and use this config: "error_description": "Client is unauthorized to retrieve access tokens using this method." I get this error: $ rclone -v -drive-impersonate ls drive-appfolder:ĥ 12:59:12 Failed to ls: couldn't list directory: Get : oauth2: cannot fetch token: 401 Unauthorized
If I put in the “One or More API Scopes” field (last point under “2.” in the description) and use this config: I’m trying to set up a Google Drive remote with a service account as described here, the only difference being that I want to use the scope instead of the one, and it doesn’t work.
0 kommentar(er)
