remote: Write access to repository not granted.

[tristanrose]

Select Topic Area

Product Feedback

Body

hi there,

i am getting a terminal error saying:

remote: Write access to repository not granted.
fatal: unable to access 'https://github.com/@username/repo.git/': The requested URL returned error: 403

If I am the owner of the repo, why do I not have write access? I created a fine-grained token for this repo but still, nothing.

suggestions from those who solved ran into and solved this before? thanks

[chris-c-thomas]

Is that the actual error returned or did you edit it slightly to remove info?

In either case it's likely trying to write to the repository either as a different configured user or no configured user at all. Try running git config --list and see what's returned. Hopefully should match the owner account of the repo.

Also, was this the process you took when cloning to use the token? GitHub Docs: Using a token on the command line

[tristanrose]

@chris-c-thomas yep, edited url. but doubled checked url is the exact match to git remote add origin <URL>

just ran git config --list, name and email are synced correct.

but unfortunately, no. i'm not even getting to the point where i can enter my user and pass (token). this err is happening before.

i am getting this err as soon as i enter git push -u origin main

[chris-c-thomas]

Right, you won't be able to push anything until things are configured to use your token instead of your old password which is likely what's happening. That's why I had asked if when you originally cloned the repository you entered your token like this here?

You can update your cached credentials to your token by following this doc. There's a link in there about changing to the Git Credential Manager if you prefer something like that.

You can use the GitHub CLI as well. Running gh auth login will let you setup your credentials using your token instead of your old password.

Give these approaches a shot and let me know how it goes.

[tristanrose]

brilliant man thanks, clearing cache following this doc did the trick :)

[chris-c-thomas]

Awesome! Glad we got it working.

[sayedsadat98]

Awesome! Thanks for the guide! Cheers!

[Sadiq-Rashid]

The "gh auth login" command helps you set up your credentials using token instead of traditional your password.
The guide was helpful, Cheers!

[kitfbgh]

Hi guys, I have the same problem but in a different context.
I use the Personal Access Token (Classic) in Travis CI to push tags, and I can push tags normally on January 16, 2023 But then came the 403 error now

suggestions from those who solved ran into and solved this before? thanks

[chris-c-thomas]

Well it's likely to be along the same lines. Most likely your password is cached to your user.email and your token isn't being used instead. Thus, the 403.

I'd recommend one these two approaches:

1. You can update your credentials in the keychain by following this guide
2. You can cache your GitHub credentials using the GitHub CLI or Git Credential Manager following this guide

All in all, both of those come from this main article about Personal Access Tokens in general. You'll want to follow them carefully so your config is set to use your token for the repos that require it.

[kitfbgh]

I tried, it didn't help me.
I'm in a CI environment.
Every establishment comes out of image....

[kesselly4099]

the reason is sample try to logout using this command $ gh auth logout and go back to GitHub create a new token do forget to give the token the permission when generate, select all the permissions you want the token to have before generating , the go back and to the command line and login in using $gh auth login

[Chaisenberg9k]

This was it. Thank you. Everyone over complicated everything

[bobeymcool]

Finally using the Credential Manager Git Credential Manager worked for me..

[indian0ch]

You just installed it?

[dyagzy]

I 'm not a vim or bash savvy developer more especially because I am new to programming. I have a work git account which is associated with my work aws account. With this account, I can push and pull from my work repository. Now I also have a personal git account which I use for personal development. Over the last 1 years or more I haven't used my personal git account but my work account. Recently I decided to fork a private repo with my personal account and got 403 error. I knew instantly that the problem is due to "multiple hit account on same machine". I have applied all the steps in the Git Credential Manager , with this I was able to fork this private repo with my personal account and then I couldn't pull or push to my work git repo any more, I had to revert all the changes. My question is how do I switch between different git account without going through the complicated SSH guides which I have been seeing around. I have tried the Git Credential Manger as stated above , I have also tried setting up my intelliji IDE but with this I can only use one account per time and can't switch

[alexurassa]

This happened because credentials have changed in remote but not updated in your local git credential store.

So you may use Git Credential Manager (GCM) to setup so that new credentials from remote will be synced with your local credentials.

Basically there you will follow these two main steps:

• Install Git Credential Manager (GCM) if you haven't already.
• Configure Git to use GCM

[Duhduh420]

Csyny

[kesselly4099]

the reason is sample try to logout using this command $ gh auth logout and go back to GitHub create a new token do forget to give the token the permission when generate, select all the permissions you want the token to have before generating , the go back and to the command line and login in using $gh auth login

[Duhduh420]

git remote add origin https://github.com/Duhduh420/Duhduh420.git
git branch -M main
git push -u origin main

[gonzalezivan90]

The new key generated here (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#using-a-personal-access-token-on-the-command-line) must have "writing" permissions. Be sure to click on those options when create the new key. That's how it works for me

[kerryj89]

If you landed here because of fatal: unable to access 'https://github.com/<your-company>/<your-repo>.git/' or similar issue in GitHub Actions suddenly, I found that I had to explicitly state the permissions in the yaml workflow file now as described above.

I don't know if some change propagated from GitHub or organizational level and I just missed the news, but today my GitHub Actions workflow was failing with the above error. My workflow pushes tags back to the repo through our own GitHub App. I reinstalled the app to the organization and to my repository and triple checked my App permissions. Unless I missed some new permission, everything was set as it was days ago.

HOWEVER... reading through the raw GitHub workflow logs drew a different picture:

Working 2 days ago:

2023-10-18T22:05:43.0996961Z ##[group]GITHUB_TOKEN Permissions
2023-10-18T22:05:43.0999064Z Actions: write
2023-10-18T22:05:43.0999735Z Checks: write
2023-10-18T22:05:43.1000452Z Contents: write
2023-10-18T22:05:43.1001194Z Deployments: write
2023-10-18T22:05:43.1001714Z Discussions: write
2023-10-18T22:05:43.1002296Z Issues: write
2023-10-18T22:05:43.1002855Z Metadata: read
2023-10-18T22:05:43.1003338Z Packages: write
2023-10-18T22:05:43.1003919Z Pages: write
2023-10-18T22:05:43.1004406Z PullRequests: write
2023-10-18T22:05:43.1004999Z RepositoryProjects: write
2023-10-18T22:05:43.1005892Z SecurityEvents: write
2023-10-18T22:05:43.1006436Z Statuses: write
2023-10-18T22:05:43.1006972Z ##[endgroup]

Error today:

2023-10-20T21:00:35.4030454Z ##[group]GITHUB_TOKEN Permissions
2023-10-20T21:00:35.4032814Z Contents: read
2023-10-20T21:00:35.4033545Z Metadata: read
2023-10-20T21:00:35.4034285Z Packages: read
2023-10-20T21:00:35.4034945Z ##[endgroup]

It seems GitHub (or my organization) is preventing GitHub App permissions from casting its wide permission net implicitly to my workflow. After adding back the missing permissions from 2 days ago into my workflow yaml, it started working again.

Edit: Leaving this up since it may still be helpful, but I just learned that our org upgraded to GitHub Enterprise which I guess affected workflows.

[serban-seeq]

I believe we hit the same issue when I was trying to run git push origin <branchname> as part of an action step. The odd thing is it works for all branches except main

[Duhduh420]

Lol

…

On Fri, Oct 20, 2023, 6:33 PM Kerry Johnson ***@***.***> wrote: If you landed here because of fatal: unable to access 'https://github.com/ <your-company>/<your-repo>.git/' or similar issue in GitHub Actions suddenly, I found that I had to explicitly state the permissions in the yaml workflow file now as described above. I don't know if some change propagated from GitHub or organizational level and I just missed the news, but today my GitHub Actions workflow was failing with the above error. My workflow pushes tags back to the repo through our own GitHub App. I reinstalled the app to the organization and to my repository and triple checked my App permissions. Unless I missed some new permission, everything was set as it was days ago. HOWEVER... reading through the raw GitHub workflow logs drew a different picture: Working 2 days ago: 2023-10-18T22:05:43.0996961Z ##[group]GITHUB_TOKEN Permissions 2023-10-18T22:05:43.0999064Z Actions: write 2023-10-18T22:05:43.0999735Z Checks: write 2023-10-18T22:05:43.1000452Z Contents: write 2023-10-18T22:05:43.1001194Z Deployments: write 2023-10-18T22:05:43.1001714Z Discussions: write 2023-10-18T22:05:43.1002296Z Issues: write 2023-10-18T22:05:43.1002855Z Metadata: read 2023-10-18T22:05:43.1003338Z Packages: write 2023-10-18T22:05:43.1003919Z Pages: write 2023-10-18T22:05:43.1004406Z PullRequests: write 2023-10-18T22:05:43.1004999Z RepositoryProjects: write 2023-10-18T22:05:43.1005892Z SecurityEvents: write 2023-10-18T22:05:43.1006436Z Statuses: write 2023-10-18T22:05:43.1006972Z ##[endgroup] Error today: 2023-10-20T21:00:35.4030454Z ##[group]GITHUB_TOKEN Permissions 2023-10-20T21:00:35.4032814Z Contents: read 2023-10-20T21:00:35.4033545Z Metadata: read 2023-10-20T21:00:35.4034285Z Packages: read 2023-10-20T21:00:35.4034945Z ##[endgroup] It seems GitHub (or my organization) is preventing GitHub App permissions from casting its wide permission net implicitly to my workflow. After adding back the missing permissions from 2 days ago into my workflow yaml, it started working again. — Reply to this email directly, view it on GitHub <#46398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBHJCHNKAN5K2DZG63KVFBLYAL35BAVCNFSM6AAAAAAURRSNFOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TGNBTG4YDQ> . You are receiving this because you commented.Message ID: ***@***.***>

[Aristarque04]

not get any results guys any other way?

[Hamed-Hasan]

It seems like you're encountering a 403 error, indicating that there's an issue with write access to your GitHub repository. This could be related to your authentication token or repository settings. Let's troubleshoot this:

1. Check Token Permissions:
   Ensure that the personal access token you generated has the necessary permissions. Make sure it has "repo" or "public_repo" scope if your repository is public, and "repo" scope for private repositories.

2. Token Usage:
   Confirm that you are using the correct token. Sometimes, users accidentally use their password instead of the access token. Update your Git credentials to use the correct token.

   git remote set-url origin https://<token>@github.com/username/repo.git

3. Verify Repository Access:
   Double-check the repository settings to ensure that you have the appropriate access level (write access) as the owner. Go to your repository on GitHub, navigate to "Settings," then "Manage access" to confirm your access level.

4. Token Regeneration:
   If the issue persists, try regenerating a new access token and update your Git credentials with the new token.

5. HTTPS vs. SSH:
   Ensure that you are using the correct URL. If you are using HTTPS, make sure the remote URL is correct. If you are using SSH, confirm that your SSH key is correctly set up.