Git Push Error: insufficient permission for adding an object to repository database

The sumplest solution is:

From the project dir:

sudo chmod 777 -R .git/objects

just copy and paste this into your own terminal.

sudo chown -R "${USER:-$(id -un)}" .

You need to copy and paste this command on your terminal :-

sudo chmod 777 -R .git/objects

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"

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)

Works for me

sudo chmod -R g+rwX .

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.

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

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.

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.

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.

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".

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.

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.

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"

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"

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.

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.