Cannot skip the web-based authorization flow in config of GCP

What is the problem you are having with rclone?

I'm running the config config on a GCE VM. The VM has a attached service account which is assigned both legacyBucketReader and legacyBucketWriter for a bucket. I'm able to use gsutil to list/read/write to that bucket using the application default credentials (ADC) without a service account key or configuration file, or having done any user account authentication because ADC will use the attached service account if none is set.

When I run rclone config I get to the point where it asks me to "Use auto config?". Choosing either option seems to initiate the web-based authorization flow (browser or local web server prompt). However, since I have an attached service account I don't really want to either auto configuration as I don't need too (and don't want too) as ADC will fall back to using the attached service account. If it had a "s - skip" option for this use case I think that would solve the problem.

The only workaround I've found was to use config and give it a bogus service_account_file, which then seems to make it skip the auto config step. I then go back and delete the bogus key/value from the config and everything then appears to work as expected.

What is your rclone version (output from rclone version)

clone v1.56.0

  • os/version: ubuntu 20.04 (64 bit)
  • os/kernel: 5.4.0-1043-gcp (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.16.5
  • go/linking: static
  • go/tags: none

Which OS you are using and how many bits (eg Windows 7, 64 bit)

ubuntu 20.04 (64 bit)

Which cloud storage system are you using? (eg Google Drive)

Google Cloud Storage

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone config

My workaround:

rclone config create gs 'google cloud storage' \
   location $(REGION) \
   storage_class REGIONAL \
   service_account_file '/tmp/foo'
sed -ie '/service_account_file/d' $(rclone config file | sed 1d)

hello and welcome to the forum,

this seems like a feature request, not a bug.

I guess you could consider it as a new feature. I would think defaulting to the attached service account would be a common use case and does seem to work, if you manipulate the config file after its creation.