0
votes

Having a rather strange issue - imaged a hard drive that had an active (and working) install of gsutil with Python 2.7.10 on Windows 8.1, booted it back up on an identical machine, and now every time I try to run a command with gsutil, I get the error "Failure: invalid_grant".

Here's the full text of the error:

C:\Windows\system32>c:\Python27\python.exe c:\gsutil\gsutil ls gs://twinpreviews

INFO 1021 00:52:48.415000 multistore_file.py] Error decoding credential, skippin
g
Traceback (most recent call last):
  File "c:\gsutil\third_party\oauth2client\oauth2client\multistore_file.py", lin
e 381, in _refresh_data_cache
    (key, credential) = self._decode_credential_from_json(cred_entry)
  File "c:\gsutil\third_party\oauth2client\oauth2client\multistore_file.py", lin
e 400, in _decode_credential_from_json
    credential = Credentials.new_from_json(json.dumps(cred_entry['credential']))

  File "c:\gsutil\third_party\oauth2client\oauth2client\client.py", line 292, in
 new_from_json
    return from_json(s)
  File "c:\gsutil\third_party\gcs-oauth2-boto-plugin\gcs_oauth2_boto_plugin\oaut
h2_client.py", line 465, in from_json
    data['token_expiry'], EXPIRY_FORMAT)
TypeError: must be string, not None
Failure: invalid_grant.

I've attempted to re-run the configuration multiple times - note that this error only stays with a service account, and does not occur if I use browser-based authentication.

I have also attempted to delete the .boto file in my home directory, along with the .gsutil folder in my home directory, then re-run gsutil config -e multiple times to no avail.

I have also created a new set of credentials and have tried a new .json key file, but still no success.

Any suggestions? Hoping someone here has had the same issue and has found a solution. Thanks!

1
It looks like there is still some stale file attempting to be loaded by multistore_file.py. If you run your command with the debug flag (gsutil -D ls ...) you should hopefully be able to see the file name in the output, then you can delete the file. - Travis Hobrla
Solved the problem! Turns out the clock on the machine was off (couple of days in the future), and apparently, gsutil does not pay any attention to that when setting the access key expiration time. Quite disappointing to find out that was the issue, but glad it is now solved. - Richard Berwick
The access key expiration time is set by the service, not by gsutil. Still, it would be good if gsutil could provide a better error message in the case of an expired token. I created github.com/GoogleCloudPlatform/gsutil/issues/307 to track this. - Travis Hobrla
Travis - thank you. I am somewhat surprised that it does not compare the current time to the time that Google has listed, but I guess that is rarely an issue. - Richard Berwick

1 Answers

1
votes

Solved the problem!

Turns out the system clock on the machine was off (couple of days in the future), and apparently, gsutil does not pay any attention to that when setting the access key expiration time.

Quite disappointing to find out that was the issue, but glad it is now solved.