You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a dsub-executed script that uses environment variables to determine which files to localize from storage using gsutil from a large list. (I do this instead of mounting because of the low reliability of gcsfuse.)
When running on the google backend provider, this approach works great even though I haven't explicitly stored any google cloud credentials within the Docker image.
But when running with the local provider, the lack of credentials is a problem when I try to run gsutil within the docker image:
ServiceException: 401 Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object. Permission 'storage.objects.get' denied on resource (or it may not exist).
CommandException: 1 file/object could not be transferred.
Is there a pointer to how we might get gcloud-in-Docker to work for easier local troubleshooting? I tried passing --credentials-file but this didn't seem to have any effect on the local provider.
The text was updated successfully, but these errors were encountered:
but the local provider sets environment variables too early. It should set the environment variables only for the "user command", but it ends up setting them before the localization command.
I have a dsub-executed script that uses environment variables to determine which files to localize from storage using
gsutil
from a large list. (I do this instead of mounting because of the low reliability of gcsfuse.)When running on the google backend provider, this approach works great even though I haven't explicitly stored any google cloud credentials within the Docker image.
But when running with the local provider, the lack of credentials is a problem when I try to run gsutil within the docker image:
Is there a pointer to how we might get gcloud-in-Docker to work for easier local troubleshooting? I tried passing
--credentials-file
but this didn't seem to have any effect on the local provider.The text was updated successfully, but these errors were encountered: