Getting underling S3 URL
# ❓ Questions & Help

<!-- The GitHub issue tracker is primarly intended for bugs, feature requests,
     new models and benchmarks, and migration questions. For all other questions,
     we direct you to the Hugging Face forum: https://discuss.huggingface.co/ .
     You can also try Stack Overflow (SO) where a whole community of PyTorch and
     Tensorflow enthusiast can help you out. In this case, make sure to tag your
     question with the right deep learning framework as well as the
     huggingface-transformers tag: 
     https://stackoverflow.com/questions/tagged/huggingface-transformers 
     -->

## Details
The high performance cluster environment at my work has been great for working with transformers. The downside however is that most access to the internet has been locked down. This means that I have been manually bringing in the models. This is somewhat problematic since it is a laborious process and I have been behind on being able to update to the newest models. 

The IT team has however said that they would be able to white list a specific S3 bucket. When I see the link to the models, I see that it is of the form: https://s3.amazonaws.com/models.huggingface.co rather than the usual https://bucket-name.s3.Region.amazonaws.com.

Is there any chance I could obtain that second format for the bucket?


probably @julien-c can help here<|||||>By default the library actually downloads model weights from `cdn.huggingface.co` so you might want to whitelist that domain.

For config files, we do download from S3. You can check the urls in the model pages' file lists e.g. https://huggingface.co/bert-base-multilingual-cased#list-files

and then replace the prefix:
`https://s3.amazonaws.com/models.huggingface.co/`
by
`http://models.huggingface.co.s3.amazonaws.com/`
<|||||>I experienced this problem and have found at least one cause to it. I added a print to the library to print what URL it was actually fetching. curl-ing that URL was no problem, but from within the package, I got a different response. I then discovered that I was able to run as root with sudo. I then straced with both my regular user and my root user and diffed the results. Then i figured out that my regular user had a .netrc-file in the home directory. Renaming that fixed the issue for me. Only took 7 hours :-\<|||||>This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
