'Git Push Error: insufficient permission for adding an object to repository database
When I try to push to a shared git remote, I get the following error:
insufficient permission for adding an object to repository database
Then I read about a fix here: Fix This worked for the next push, since all of the files were of the correct group, but the next time someone pushed up a change it made a new item in the objects folder that had their default group as the group. The only thing I can think of is to change all of the developer's default group for items they check in, but that seems like a hack. Any ideas? Thanks.
Solution 1:[1]
For Ubuntu (or any Linux)
From project root,
cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *
You can tell yourname and yourgroup by:
# for yourname
whoami
# for yourgroup
id -g -n <yourname>
Note: remember the star at the end of the sudo line
Solution 2:[2]
use the following command, works like magic
sudo chown -R "${USER:-$(id -un)}" .
type the command exactly as it is (with extra spaces and one dot at the end)
Solution 3:[3]
sudo chmod -R ug+w .;
Basically, .git/objects file does not have write permissions. The above line grants permission to all the files and folders in the directory.
Solution 4:[4]
I just wanted to add my solution. I had a repo on OS X that had ownership of root on some directories and Home (which is my user directory) on others which caused the same error listed above.
The solution was simple thankfully. From terminal:
sudo chown -R Home projectdirectory
Solution 5:[5]
Solved for me... just this:
sudo chmod 777 -R .git/objects
Solution 6:[6]
A good way to debug this is the next time it happens, SSH into the remote repo, cd into the objects folder and do an ls -al.
If you see 2-3 files with different user:group ownership than this is the problem.
It's happened to me in the past with some legacy scripts access our git repo and usually means a different (unix) user pushed / modified files last and your user doesn't have permissions to overwrite those files. You should create a shared git group that all git-enabled users are in and then recursively chgrp the objects folder and it's contents so that it's group ownership is the shared git group.
You should also add a sticky bit on the folder so that all the files created in the folder will always have the group of git.
chmod g+s directory-name
Update: I didn't know about core.sharedRepository. Good to know, though it probably just does the above.
Solution 7:[7]
The sumplest solution is:
From the project dir:
sudo chmod 777 -R .git/objects
Solution 8:[8]
just copy and paste this into your own terminal.
sudo chown -R "${USER:-$(id -un)}" .
Solution 9:[9]
This can easily happen if you ran git init with a different user from the one you are planning to use when pushing changes.
If you blindly follow the instructions on [1] this will happen as you probably created the git-user as root and then immediately moved on to git init without changing user in between.
[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
Solution 10:[10]
Linux, macOS:
cd .git/
sudo chown -R name:group *
where name is your username and group is the group that your username belongs to.
Solution 11:[11]
After you add some stuff... commit them and after all finished push it! BANG!! Start all problems... As you should notice there are some differences in the way both new and existent projects were defined. If some other person tries to add/commit/push same files, or content (git keep both as same objects), we will face the following error:
$ git push
Counting objects: 31, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (21/21), 2.07 KiB | 0 bytes/s, done.
Total 21 (delta 12), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object
To solve this problem you have to have something in mind operational system's permissions system as you are restricted by it in this case. Tu understand better the problem, go ahead and check your git object's folder (.git/objects). You will probably see something like that:
<your user_name>@<the machine name> objects]$ ls -la
total 200
drwxr-xr-x 25 <your user_name> <group_name> 2048 Feb 10 09:28 .
drwxr-xr-x 3 <his user_name> <group_name> 1024 Feb 3 15:06 ..
drwxr-xr-x 2 <his user_name> <group_name> 1024 Jan 31 13:39 02
drwxr-xr-x 2 <his user_name> <group_name> 1024 Feb 3 13:24 08
*Note that those file's permissions were granted only for your users, no one will never can changed it... *
Level u g o
Permission rwx r-x ---
Binary 111 101 000
Octal 7 5 0
SOLVING THE PROBLEM
If you have super user permission, you can go forward and change all permissions by yourself using the step two, in any-other case you will need to ask all users with objects created with their users, use the following command to know who they are:
$ ls -la | awk '{print $3}' | sort -u
<your user_name>
<his user_name>
Now you and all file's owner users will have to change those files permission, doing:
$ chmod -R 774 .
After that you will need to add a new property that is equivalent to --shared=group done for the new repository, according to the documentation, this make the repository group-writable, do it executing:
$ git config core.sharedRepository group
Solution 12:[12]
I'll add my two cents just as a way to discover files with a specific ownership inside a directory.
The issue was caused by running some git command as root. The received message was:
$ git commit -a -m "fix xxx"
error: insufficient permission for adding an object to repository database .git/objects
error: setup.sh: failed to insert into database
I first looked at git config -l, then I resolved with:
find .git/ -exec stat --format="%G %n" {} + |grep root
chown -R $(id -un):$(id -gn) .git/objects/
git commit -a -m "fixed git objects ownership"
Solution 13:[13]
You need to copy and paste this command on your terminal :-
sudo chmod 777 -R .git/objects
Solution 14:[14]
For my case none of the suggestions worked. I'm on Windows and this worked for me:
- Copy the remote repo into another folder
- Share the folder and give appropriate permissions.
- Make sure you can access the folder from your local machine.
- Add this repo as another remote repo in your local repo. (
git remote add foo //SERVERNAME/path/to/copied/git) - Push to foo.
git push foo master. Did it worked? Great! Now delete not-working repo and rename this into whatever it was before. Make sure permissions and share property remains the same.
Solution 15:[15]
I hit this same issue. Reading around here I realised it was file permissions the message was referring to. The fix , for me, was in:
/etc/inetd.d/git-gpv
It was starting git-daemon as user 'nobody' so lacked the write permission.
# Who When What
# GPV 20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV 20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
(I doubt other call their inetd conf file git-gpv . Commonly it would be directly in /etc/inetd.conf)
Solution 16:[16]
Works for me
sudo chmod -R g+rwX .
Solution 17:[17]
You need the sufficient write permissions on the directory that you are pushing to.
In my case: Windows 2008 server
right click on git repo directory or parent directory.
Properties > Sharing tab > Advanced Sharing > Permissions > make sure the user has appropriate access rights.
Solution 18:[18]
There is a possibility also that you added another local repository with the same alias. As an example, you now have 2 local folders referred to as origin so when you try to push, the remote repository will not accept you credentials.
Rename the local repository aliases, you can follow this link https://stackoverflow.com/a/26651835/2270348
Maybe you can leave 1 local repository of your liking as origin and the others rename them for example from origin to anotherorigin. Remember these are just aliases and all you need to do is remember the new aliases and their respective remote branches.
Solution 19:[19]
I got this when pulling into an Rstudio project. I realised I forgot to do:
sudo rstudio
on program startup. In fact as there's another bug I've got, I need to actually do:
sudo rstudio --no-sandbox
Solution 20:[20]
I was getting this problem with a remote repository on a Samba share; I pulled successfully from this remote, but failed when pushing to it.
The cause of the error was incorrect credentials in my ~/.smbcredentials file.
Solution 21:[21]
After using git for a long time without problems, I encountered this problem today. After some reflection, I realized I changed my umask earlier today from 022 to something else.
All the answers by other people are helpful, i.e., do chmod for the offending directories. But the root cause is my new umask which will always cause a new problem down the road whenever a new directory is created under .git/object/. So, the long term solution for me is to change umask back to 022.
Solution 22:[22]
I was getting this error when running a remote development development machine using Vagrant. None of the above solutions worked because all the files had the correct permissions.
I fixed it by changing config.vm.box = "hasicorp/bionic64" to config.vm.box = "bento/ubuntu-20.10".
Solution 23:[23]
In my case, the solution was simply to git commit again.
The problem went away automatically.
What happened? I used ^C (Control-C) to break out of writing a bad commit message. (I pasted the wrong message from the wrong clipboard.) So I assume the process was temporarily frozen in the background, which locked up the database temporarily.
Solution 24:[24]
I got this issue resolved by making use of ssh:// based URL instead of http:// based URL.
I had cloned the repository quite a few days earlier using the http:// based URL. In between the cloning and pushing, I had to enable 2FA on my account and subsequently get my public key added to the code repository.
Due to enabled 2FA the http:// URL was not working properly.
Solution 25:[25]
Make sure you open the command line prompt as admin. Then, make sure project files are not read-only.
In windows, you can check this by right-clicking on project folder -> click "Show more options" -> click "Properties" -> deselect "Read-only" -> click "Apply"
Solution 26:[26]
I faced this problem too many times but every time it occurs I try to push or commit using the sudo command and the after typing my password i push or commit without sudo for example
sudo git commit -m "message"
then after typing my password i again
git commit -m "message"
Solution 27:[27]
I just tried sudo git commit -m "XY" then I canceled it with CTRL + C and tried again with git commit -m "XY" then it suddenly worked.
Solution 28:[28]
Repair Permissions
I used this to repair my .git folder, the answer of @richard-hansen was missing the user.
First you need to go into the .git folder.
cd /path/to/repo/.git
Then execute these commands.
sudo chown -R user:groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +
This will also fix all submodules.
Solution 29:[29]
There is one more solution to this problem which can be reproduced when you work with multiple running docker containers and try to change and commit/push something.
In my case I could not commit anything while all the containers where up. But as soon as I killed them - I was able to commit without any issues.
I did not study the reason for such a behavior much, but I can guess that the code which you are changing locally is reused in a docker container and as it's being run from root user and thus it can change some permissions of the files it works with - this can cause an issue.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow