PAT's to clone using HTTPS won't work

Please help fill in this template with all the details to help others help you more efficiently. Use formatting blocks for code, config, logs and ensure to remove sensitive data.

Problem to solve

I’m part of an Enterprise group on Gitlab.com, our structure is as follows:

ORG GROUP > Subgroup_Teams
ORG GROUP > Subgroup_Repos

Subgroup_Teams > Subgroup_Team_1
Subgroup_Teams > Subgroup_Team_2

Subgroup_Repos > Subgroup_Project_1
Subgroup_Repos > Subgroup_Project_2

Subgroup_Project_1 > Repo_1
Subgroup_Project_2 > Repo_2

Subgroup_Project_1 has invited Group Subgroup_Team_1 as Developers.

I’m part of Subgroup_Team_1 but also Owner of ORG_GROUP.

Created a PAT as described in the docs. Now, when I go to clone the repo using:

git clone "https://myaccount:token@gitlab.com/ORG_GORUP/Subgroup_Repos/Subgroup_Project_1/rRepo_1.git"

• What are you seeing, and how does that differ from what you expect to see?

remote: Git access over HTTP is not allowed
fatal: unable to access "https://myusername:token@gitlab.com/ORG_GORUP/Subgroup_Repos/Subgroup_Project_1/rRepo_1.git/": The requested URL returned error: 403

fatal: unable to access "https://myaccount:token@gitlab.com/ORG_GORUP/Subgroup_Repos/Subgroup_Project_1/rRepo_1.git": The requested URL returned error: 403

Steps to reproduce

Which troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?

Tried multiple tokens, even tried service accounts (got the same result)

Configuration

Provide screenshots from the GitLab UI showing relevant configuration, if applicable.
On self-managed instances, add the relevant configuration settings or changes.

Versions

Please add an x whether options apply, and add the version information.

• Self-managed
• GitLab.com SaaS
• Dedicated

Versions

• GitLab (Web: /help or self-managed system information sudo gitlab-rake gitlab:env:info):

Helpful resources

1. Check the FAQ for helpful documentation, issues/bugs/feature proposals, and troubleshooting tips.
2. Before opening a new topic, make sure to search for keywords in the forum search
3. Check the GitLab project for existing issues. If you encounter a bug, please create a bug report issue.
4. Review existing troubleshooting docs.

Thanks for taking the time to be thorough in your request, it really helps!

Hi,

Just to make sure - you have added correct scopes to your token (minimum read_repository)? Make sure the token is not expired.

Yep - token was generated 5 minutes before trying and has ALL boxes checked.

You sure you’re using Personal access token, and not some other project’s Project Access Token?

Also, I’d not check all the boxes, just the required ones. So maybe just try with read_repository or write_repository.

Thanks! Just tried that as well… I created a brand new token from my Profile with just two permissions. Same error.

image720×438 57 KB

We have SAML enabled, but that shouldn’t prevent PAT’s from working.

Sounds like the Git access was changed to SSH only. Navigate into the group settings and search for git access to identify whether HTTPS and SSH are selected, like shown in the screenshot.

image769×777 88.4 KB

You sir are the GOAT!

@dnsmichi - I should be able to use PAT’s for CI/CD, right?

You can, but it is recommended to use Project Access Tokens or Group Access Tokens in CI/CD which can be scoped and tracked (audit events) for a specific purpose. Personal Access Tokens might have too much access (everything your account is able to read/write depending on scope).

If I may add to what @dnsmichi said - I’d recommend using CI_JOB_TOKEN where/if applicable. They are used by GitLab Runners as well while cloning git repos.

There are many options in GitLab, I’d recommend checking out this page and finding a suitable token for your needs. Project (or Group, if you want to handle something on group level) Access Tokens are the most versatile, though.

Thank you for the suggestion. The way I read about Group Deploy Tokens is that a token is valid only for the repos directly within the Group. Unfortunately, we have a ton of sub-groups, and are trying to access repos from Subgroup_Project_2 in Repo_1 CI/CD pipelines.