Error could not lock config file c program files git etc gitconfig permission denied

Hey no problem, thanks for the reply!

So it should have read, write, AND execute under permissions? I recall in my adventures in keychain access, only read + write were allowed to (me), system, and everyone.
I’ll definitely try that command, thanks!

…

error: could not lock config file .git/config: Permission denied #675

/.yadr to update and was greeted with the following error message error: could not lock config file .git/config: Permission denied

The text was updated successfully, but these errors were encountered:

I’m getting this issue with the most recent version.

Edit: I was able to resolve using chmod .

Hey @scottenriquez could you elaborate for me? What did you do with chmod to fix?

Sorry for the late reply. If I remember correctly, I simply used the following command: chmod 777

/.yadr/.git/config to grant read, write, and execute to everyone. Depending on your setup, you may want to lock down the permissions a bit more. Also note that this is assuming that YADR has been installed in your home directory. If you used the install.sh script, you should be good to go.

/.yadr/.git/config to grant read, write, and execute to everyone. Depending on your setup, you may want to lock down the permissions a bit more. Also note that this is assuming that YADR has been installed in your home directory. If you used the install.sh script, you should be good to go. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

I’m assuming some other tool reading/writing to that file (say Git Tower or whatever) changed the file permissions.

We didn’t have more complaints about this and it’s been a while, so I’m taking the liberty of closing this issue, ok? Feel free to reopen it if needed

this is my error. I cant even declare my global username and useremail

Rename from ‘C:/Users/mallioruganti/.gitconfig.lock’ to ‘C:/Users/mallioruganti/.gitconfig’ failed. Should I try again? (y/n) y

Corporate security policy prohibits writing to the «H:» path, directly. I have an «H:$user» directory that I can write to, however, the global (and GPO enforced) home directory variable is incomplete, and points to «H:» directly.

Because I have found no reasonably sane method to actually adjust the default location that the git for windows tool(s) use (I’ve tried 3 different packages, but they all seem to tie back to the same base project code). So I’m ‘stuck’.

error: could not lock config file H://.gitconfig: Permission denied

I wasn’t able to create a local .gitconfig, since the windows GPO doesn’t allow viewing hidden files, or setting the extensions of files.
But I was able to use winSCP to copy my linux .gitconfig directly in to the local repo on windows and now I’m able to use my direct rubymine integration, and skip using the github desktop for windows interface. (though I am pointing rubymine to the git executable that comes with github desktop)

Источник

error of «could not lock config file .git/config: Permission denied» due to unstaged changes; in Homebrew while installing openJDK 8

I’m trying to install OpenJdk 8 on a MacOS recently updated to Mojave. The install command was

It results in the following error:

But when I do ‘git status’ from within the /usr/local/Homebrew directory, it says ‘nothing to commit, working tree clean’.

I looked at the hidden .git directories under/Homebrew. Before yesterday, it hadn’t been touched in a year. I don’t generally mess with it and haven’t used it to install anything in awhile.

1 Answer 1

The cannot rebase is a red herring—Git’s gotten confused by the earlier failure into thinking it needs to rebase around it, but the earlier failure is not because of changes. The actual problem is permission denied .

That problem means exactly what it says. You, as yourself, have no permission to modify these files. That means either you revoked your own permission, or you made these file as some other user. See How to fix homebrew permissions?

Linked

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Git’s famous «ERROR: Permission to .git denied to user»

I have tried googling and read through https://help.github.com/en/articles/connecting-to-github-with-ssh and various, various guides. I am unable to git push -u origin master or git push origin master ( the same command ).

I’ve had my git account for at least 2 or so years. I’ve successfully been able to create repos and push -u origin master fine on my laptop but on this desktop I’m having issues.

Here’s what I tried:

1. I have setup my git user name

2. I have setup my git user email

3. I have uploaded the contents of my /home/meder/.ssh/id_rsa.pub to github’s account page. I have verified I did not paste any whitespace

4. I have created a

/.ssh/config with these contents:

I have chmodded the .ssh to 700, id_rsa 600

5. I have added the proper remote origin without making typos : git remote add origin git@github.com:medero/cho.git

6. To confirm #5, here is my .git/config. The directory is correct and not another directory:

7. ssh git@github.com -v gives me a successful Authentication

8. One weird thing is, the username which it greets me with has t appended to it. My github username is medero , not medert .

Hi mederot! You’ve successfully authenticated, but GitHub does not provide shell access.

9. I am not behind a proxy or firewall

10. The key is offered, heres the output from -v :

11. Here are the commands I used

12. I don’t want to create a new SSH key.

13. If I git clone using ssh and make an edit, commit, and git push, I get the same exact thing.

14. Here’s the actual error:

15. I have setup my github username and github token:

$ git config —global github.user medero $ git config —global github.token 0123456789yourf0123456789tokenSets the GitHub token for all git instances on the system

16. I have confirmed my github username is NOT mederot and my github token IS CORRECT per my account page ( validated first 2 chars and last 2 chars ).

17. To confirm #16,

18. I did ssh-key add

/.ssh/id_rsa if that’s even necessary.

THEORIES:

I suspect there’s something fishy because when I get ssh authenticated, the user greeting is mederot and not medero , which is my acct. Could something in my github account possibly be incorrectly cached?

I also suspect some local ssh caching weirdness because if i mv

/.ssh/id_rsa KAKA and mv

/.ssh/id_rsa.pub POOPOO , and do ssh git@github.com -v , it still Authenticates me and says it serves my /home/meder/.ssh/id_rsa when I renamed it?! It has to be cached?!

17 Answers 17

After Googling for few days, I found this is the only question similar to my situation.

However, I just solved the problem! So I am putting my answer here to help anyone else searching for this issue.

Here is what I did:

Open «Keychain Access.app» (You can find it in Spotlight or LaunchPad)

Select «All items» in Category

Search «git»

Delete every old & strange item

Try to Push again and it just WORKED

If problem is coming on windows then remove the Credentials from the Windows history.

• Go to Credential Manager
• Go to Windows Credentials
• Delete the entries under Generic Credentials
• Try connecting again.This time , it should prompt you for the correct username and password.

On Mac, if you have multiple GitHub logins and are not using SSH, force the correct login by using:

This also works if you’re having issues pushing to a private repository.

In step 18, I assume you mean ssh-add

/.ssh/id_rsa ? If so, that explains this:

I also suspect some local ssh caching weirdness because if i mv

/.ssh/id_rsa KAKA and mv

/.ssh/id_rsa.pub POOPOO, and do ssh git@github.com -v, it still Authenticates me and says it serves my /home/meder/.ssh/id_rsa when I renamed it?! It has to be cached?!

. since the ssh-agent is caching your key.

If you look on GitHub, there is a mederot account. Are you sure that this is nothing to do with you? GitHub shouldn’t allow the same SSH public key to be added to two accounts, since when you are using the git@github.com. URLs it’s identifying the user based on the SSH key. (That this shouldn’t be allowed is confirmed here.)

So, I suspect (in decreasing order of likelihood) that one of the following is the case:

1. You created the mederot account previously and added your SSH key to it.
2. Someone else has obtained a copy of your public key and added it to the mederot GitHub account.
3. There’s a horrible bug in GitHub.

If 1 isn’t the case then I would report this to GitHub, so they can check about 2 or 3.

ssh-add -l check if there is more than one identify exists if yes, remove it by ssh-add -d «that key file»

Its due to a conflict.

Clear all keys from ssh-agent

Add the github ssh key

It should work now.

I am using Mac and the issue is solved by deleting github record from keychain access app: Here is what i did:

1. Open «Keychain Access.app» (You can find it in Spotlight orLaunchPad)
2. Select «All items» in Category
3. Search «git»
4. Delete every old & strange items Try to Push again and it just WORKED

Above steps are copied from @spyar for the ease.

I find the solution is the same as @spyar provide which is the Keychain Access app stored the old username.

There are 2 solutions for this situation:

1. Delete the info in Keychain Access by
   • Open Keychain Access app
   • Search for GitHub
   • Delete corresponding credentials

If you want to use ssh key. You just change your Repo url from https

I recently ran into this issue for on old repo on my machine that had been pushed up using https. steps 5 and 6 solved my issue by re-setting the remote url for my repo from using the https url to the ssh url

checking the remote is using the https url

then re-setting the origin to use the ssh url

verifying new remote

could now successfully git push -u origin

i’m still not sure what setting i would have changed that might have caused the push to fail when the remote is https but this was the solution to my issue

I was running into similar issue on Mac OS.

Summary

1. Make sure the repo gets cloned with correct/intended username
2. If you try to clone a repo without specifying GitHub username, it picks up the GitHub username already cached in the OSX’s Keychain Access utility
3. Hence I had to specify username while cloning the repo — git clone https://username@github.com/username/repository.git
4. When it prompts to enter password, you may have to use a use a personal access token (PAT) because support for password authentication was removed on August 13, 2021 by GitHub. Here’s some documentation around personal access tokens (PAT) and how to set up and use
5. The initial push might also require specifying username git push https://username@github.com/username/repository.git and providing PAT as password
6. On subsequent pushes, no password would be prompted as they get cached to OSX Keychain Access util. Also, I didn’t have to use the full URL to push. Just git push
   worked fine

More details about my set up/situation/issue

Essentially I was trying to work with two different GitHub (github.com) accounts (1. Work account/email & 2. Personal account/email)

Mine was a little peculiar case because I had an existing SSH key generated with my personal email when our organization was on premise before migrating our repos to public github.com and that key was also configured for Bastion AWS (Amazon Web Services). I couldn’t regenerate a new key with the same email and also I did not generate a new key with work email which would have required to update the key configured for Bastion AWS

Note: My initial set up itself wasn’t correct because at that time I didn’t have much knowledge about how to work with or use SSH keys, so I realized I set them up incorrectly

Following approach worked for me (Note that this is a work around). I fell back to using GitHub Personal Access Token (PAT) instead.

Prompted password, I entered my PAT here (which then got cached to OSX Keychain Access)

On my subsequent pushes, no password prompts and I didn’t have to use the full URL to push. Just git push
worked fine

Источник

Error: Permission denied (publickey)

In this article

A «Permission denied» error means that the server rejected your connection. There could be several reasons why, and the most common examples are explained below.

Should the sudo command or elevated privileges be used with Git?

You should not be using the sudo command or elevated privileges, such as administrator permissions, with Git. If you have a very good reason you must use sudo , then ensure you are using it with every command (it’s probably just better to use su to get a shell as root at that point). If you generate SSH keys without sudo and then try to use a command like sudo git push , you won’t be using the same keys that you generated.

Check that you are connecting to the correct server

Typing is hard, we all know it. Pay attention to what you type; you won’t be able to connect to «githib.com» or «guthub.com». In some cases, a corporate network may cause issues resolving the DNS record as well.

To make sure you are connecting to the right domain, you can enter the following command:

The connection should be made on port 22, unless you’re overriding settings to use SSH over HTTPS.

Always use the «git» user

All connections, including those for remote URLs, must be made as the «git» user. If you try to connect with your GitHub username, it will fail:

If your connection failed and you’re using a remote URL with your GitHub username, you can change the remote URL to use the «git» user.

You should verify your connection by typing:

Make sure you have a key that is being used

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

If you have GitHub Desktop installed, you can use it to clone repositories and not deal with SSH keys.

If you are using Git Bash, turn on ssh-agent:

If you are using another terminal prompt, such as Git for Windows, turn on ssh-agent:

Verify that you have a private key generated and loaded into SSH.

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

The ssh-add command should print out a long string of numbers and letters. If it does not print anything, you will need to generate a new SSH key and associate it with GitHub.

Tip: On most systems the default private keys (

/.ssh/identity ) are automatically added to the SSH authentication agent. You shouldn’t need to run ssh-add path/to/key unless you override the file name when you generate a key.

Getting more details

You can also check that the key is being used by trying to connect to git@github.com :

In that example, we did not have any keys for SSH to use. The «-1» at the end of the «identity file» lines means SSH couldn’t find a file to use. Later on, the «Trying private key» lines also indicate that no file was found. If a file existed, those lines would be «1» and «Offering public key», respectively:

Verify the public key is attached to your account

You must provide your public key to GitHub to establish a secure connection.

Start SSH agent in the background.

Find and take a note of your public key fingerprint.

In the upper-right corner of any page, click your profile photo, then click Settings.

In the «Access» section of the sidebar, click

SSH and GPG keys.

Compare the list of SSH keys with the output from the ssh-add command.

Open the command line.

Start SSH agent in the background.

Find and take a note of your public key fingerprint.

In the upper-right corner of any page, click your profile photo, then click Settings.

In the «Access» section of the sidebar, click

SSH and GPG keys.

Compare the list of SSH keys with the output from the ssh-add command.

Start SSH agent in the background.

Find and take a note of your public key fingerprint. If you’re using OpenSSH 6.7 or older:

If you’re using OpenSSH 6.8 or newer:

In the upper-right corner of any page, click your profile photo, then click Settings.

In the «Access» section of the sidebar, click

SSH and GPG keys.

Compare the list of SSH keys with the output from the ssh-add command.

If you don’t see your public key in GitHub, you’ll need to add your SSH key to GitHub to associate it with your computer.

Warning: If you see an SSH key you’re not familiar with on GitHub, delete it immediately and contact GitHub Support, for further help. An unidentified public key may indicate a possible security concern. For more information, see «Reviewing your SSH keys.»

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Источник

Question:

I would like to run this Git command:

git submodule add https://github.com/example/example.git

But I get this error:

Cloning into ‘C:/projects/xxx/yyy/zzz/’…
fatal: unable to access ‘https://github.com/xxx/yyy.git/‘: error setting certificate verify locations:
CAfile: C:Program Files (x86)gitbincurl-ca-bundle.crt
CApath: none
fatal: clone of ‘https://github.com/xxx/yyy.git‘ into submodule path ‘C:/projects/xxx/yyy/zzz/example’ failed

So, to fix this, I am trying to run this command:

git config —system http.sslcainfo «C:Program Files (x86)gitbincurl-ca-bundle.crt»

But I get this error message:

error: could not lock config file C:/Program Files/Git/mingw64/etc/gitconfig: Permission denied

How can I fix this?

Answer:

you need to be in admin mode to execute the command (in cmd terminal or in PowerShell (Admin) on windows10)

Open


Issue created Aug 15, 2018 by Igor Yurev@iyurev

GitLab Runner OpenShift error: could not lock config file //.gitconfig: Permission denied

Summary

Summarize the bug encountered concisely

GitLab runner with kubernetes executor wont work with privileged = false container option .

Steps to reproduce

Configure GitLab runner for working with RH OpenShift platform , configmap :

  - kind: "ConfigMap"
    apiVersion: v1
    metadata:
      name: "${APP_NAME}"
      namespace: "${NAMESPACE}"
    data:
      config.toml: |
        concurrent = 1
        check_interval = 0

        [[runners]]
          name = "openshift"
          url = "https://gitlab.consto.com/"
          token = "${TOKEN}"
          executor = "kubernetes"
          [runners.cache]
          [runners.kubernetes]
            service-account = "runner-sa"
            bearer_token_overwrite_allowed = true
            image = ""
            namespace = "${NAMESPACE}"
            namespace_overwrite_allowed = ""
            privileged = false
            service_account_overwrite_allowed = ""
            pod_annotations_overwrite_allowed = ""

SCC for service account runner-sa:

  - kind: "SecurityContextConstraints"
    apiVersion: v1
    metadata:
      name: gitlab-runner
    allowPrivilegedContainer: yes
    runAsUser:
      type: RunAsAny
    seLinuxContext:
      type: RunAsAny
    fsGroup:
      type: RunAsAny
    supplementalGroups:
      type: RunAsAny

    allowHostDirVolumePlugin: true

    users:
    - system:serviceaccount:${NAMESPACE}:runner-sa

Pipelines running only if option privileged has true value , else
I get error : error: could not lock config file //.gitconfig: Permission denied

Actual behavior

What actually happens

Expected behavior

GitLab runner working with not privileged mode .

Relevant logs and/or screenshots

Running with gitlab-runner 11.1.0 (081978aa)
  on openshift ff568bcd
"BearerToken" overwritten with "XXXXXXXX..."
Using Kubernetes namespace: building-base-images
Using Kubernetes executor with image docker-registry.consto.com/openshift3/ose-ansible:latest ...
Waiting for pod building-base-images/runner-ff568bcd-project-20-concurrent-05qvzr to be running, status is Pending
Waiting for pod building-base-images/runner-ff568bcd-project-20-concurrent-05qvzr to be running, status is Pending
Running on runner-ff568bcd-project-20-concurrent-05qvzr via gitlab-runner-01-18-s9klb...
error: could not lock config file //.gitconfig: Permission denied
ERROR: Job failed: command terminated with exit code 1

Environment description

openshift 3.10
gitlab ee 11.0.3-ee (f25aa33)

Used GitLab Runner version

gitlab-runner 11.1.0 (081978aa)

Issue

I am relatively new to the Ubuntu OS and Git.

I have installed Git on Ubuntu 20.04 by following the instruction mentioned in the following link

Getting Started Installing Git

As mention in the next step that there are three levels of Git Configuration

1. System Level Configuration – which applies to every user and all their repositories on the system
2. Global Level Configuration – which applies to the current user and all the their repositories on the system
3. Local Level Configuration – which applies to the specific repository you are working with

I was able to change the global settings of the git by using the –global option, and also change the local setting of the git by using the –local option. But when I tried to change the setting of the git on system level using –system option, I encoutered the following error by the running the command git config --system user.name "My Name"

Error:
error: could not lock config file /etc/gitconfig: Permission denied

Solution

Files under /etc/ belong to root and must be edited with root privileges:

sudo git config --system user.name "My Name"

But you’re trying to set you personal configuration in the system config. My advice is: don’t do that, use your global user config:

git config --global user.name "My Name"

Answered By – phd

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

1. Purpose

In this post, I would demonstrate how to solve the following error when using git clone in windows:

2. The reason and solution

2.1 The reason of this problem

Git has a limit of 4096 characters for a filename, except on Windows when Git is compiled with msys. It uses an older version of the Windows API and there’s a limit of 260 characters for a filename.So it’s a limitation of msys and not of Git. You can read the details here: https://github.com/msysgit/git/pull/110.

The root cause of the technical limitation of 260 chars lies within the Windows API. Microsoft’s online article Naming Files, Paths, and Namespaces describes the reasons. Because Git was originally written on Linux, there’s no such limitation. Thus the problem occurs when the original Git code is compiled on the Windows platform.

2.2 The solutions

2.2.1 Solution #1

You can solve this problem by using another Git client on Windows or set core.longpaths to true as explained in other answers.

Run the following command (Run as terminal as administrator):

git config --system core.longpaths true

If you encounter this error:

"error: could not lock config file C:Program Files (x86)Gitmingw32/etc/gitconfig: Permission denied"

You can fix the problem by running this:

git config --global core.longpaths true

The limitation to 260 chars in a path is not specific to MSYS, it’s a general Windows API imitation. This can be worked around by using Unicode paths, but that has other drawbacks, which is why core.longpaths is not enabled by default. Also note that Git for Windows it not compiled against MSYS. Instead, it’s a native Windows application that comes with a stripped-down MSYS environment.

2.2.2 Solution #2

you can Create .gitconfig and add this:

You can create above file in a project location and also in the global location. In my case the location is C:Users{name}.

2.2.3 Solution #3

To be entirely sure that it takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out, it is safer to use it this way:

git clone -c core.longpaths=true <repo-url>

-c key=value

Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out. The key is in the same format as expected by git-config1 (e.g., core.eol=true). If multiple values are given for the same key, each value will be written to the config file. This makes it safe, for example, to add additional fetch refspecs to the origin remote.

2.2.4 Solution #4

You could also try to enable long file paths in windows.

If you run Windows 10 Home Edition you could change your Registry to enable long paths.

Go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem in regedit and then set LongPathsEnabled to 1.

If you have Windows 10 Pro or Enterprise you could also use Local Group Policies.

Go to Computer Configuration → Administrative Templates → System → Filesystem in gpedit.msc, open Enable Win32 long paths and set it to Enabled.

2.3 The future

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLMSYSTEMCurrentControlSetControlFileSystem LongPathsEnabled (Type: REG_DWORD)

3. Summary

In this post, I demonstrated how to solve the Filename too long problem when using git clone commands, the key point is to understand why the error happens, you can workaround this by using git commands or just alter windows settings to avoid this problem. That’s it, thanks for your reading.