Error pushing to GitHub – insufficient permission for adding an object to repository database

I’m getting back an unusual error while trying to do a “git push” to my GitHub repository:

Counting objects: 8, done.
Delta compression using 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 1.37 KiB, done.
Total 5 (delta 2), reused 0 (delta 0)
error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object
error: unpack-objects exited with error code 128
error: unpack failed: unpack-objects abnormal exit
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to ''
  • After a clean clone from GitHub, I can edit/add/commit/push a modified file.
  • If I then repeat this a second time I get the above error.
  • I can push to other GitHub repositories just fine.
  • I’ve checked file/directory permissions on my side, and they seem OK.
  • I’m running git on Mac OS X 10.5.8

The above repository was the source of my fun for a previous Stack Overflow question (SO 1904860), so maybe the GitHub repo got corrupted. The only similar issue I’ve found via searching was an unpack failed problem reported on github. Has anybody else run into this issue before, especially when not using GitHub?

  • Amending Git Author In a Published Repo
  • how to make windows remember my passphrase key?
  • Best practice for using multiple .gitignore files
  • cherrypick not giving all the files
  • Rename remote git branch without fetch
  • Git: The Curious Case of the Missing Commits
  • Git push origin master returns Error cannot spawn … why?
  • Git one-liner to add everything (including untracked files) and commit
  • 21 Solutions collect form web for “Error pushing to GitHub – insufficient permission for adding an object to repository database”

    When you see this error outside of github, here’s a remedy.

    Got this from:

    ssh me@myserver
    cd repository/.git
    sudo chmod -R g+ws *
    sudo chgrp -R mygroup *
    git config core.sharedRepository true

    After this the git daemon should use the group file permissions when writing to .git/objects.

    Usually this problem is caused by wrong user and group permissions on your Git servers file-system. The git repository has to be owned by the user and also his group.


    If your user is called “git”, his group “gitgroup”, and the location of the Git repo is:

    then do a:

    sudo chown -R git:gitgroup path/to/repo.git/

    This fixed the git insufficient permission error for me.

    sudo chmod 777 -R .git/objects

    This happened to me when I tried to git pull. Some analysis showed that somebody had commited with root in the past, thereby creating some objects with root ownership in .git/objects.

    So I ran

    cd <repo>
    la .git/objects/

    and that showed root ownership for some objects (directories) like this:

    user@host:/repo> la .git/objects/
    total 540
    drwxr-xr-x 135 user user 4096 Jun 16 16:29 .
    drwxr-xr-x   8 user user 4096 Jun 16 16:33 ..
    drwxr-xr-x   2 user user 4096 Mar  1 17:28 01
    drwxr-xr-x   2 user user 4096 Mar  1 17:28 02
    drwxr-xr-x   2 user user 4096 Jun 16 16:27 03
    drwxr-xr-x   2 user user 4096 Mar  3 13:22 04
    drwxr-xr-x   2 root root 4096 Jun 16 16:29 05
    drwxr-xr-x   2 user user 4096 Jun 16 16:28 07
    drwxr-xr-x   2 root root 4096 Jun 16 16:29 08

    Then I ran

    sudo chown -R user:user .git/objects/

    and it worked!

    I was replacing user with my real user, of course.

    Nothing of the above worked for me. A couple of hours later I found the reason for the problem:
    I used a repo url of the type


    Unfortunately I stored a putty session with the name which was configured to login as user myOtherUser.

    So, while I thought git connects to the host with the User ‘git’, Git/TortoiseGit has connected to the putty session which uses the User myOtherUser. This leads to the exact same ..insufficient permission.. error (cause both users are in different groups).

    Solution: Rename the putty session to

    chmod should be chown, so the correct line is:

    sudo chown -R gituser:gituser objects

    Oddly enough, I had this issue on one clone of the repo I had, but not another I had. Aside from re-cloning the repo (which a coworker did to successfully get around this issue), I managed to do a “git reset” to the commit I had before the failures started. Then I re-committed the changes, and I was able to push successfully after that. So despite all the indications there was a problem on the server, in this case it apparently was indicative of some oddity in the local repo.

    If you still get this error later after setting the permissions you may need to modify your creation mask. We found our new commits (folders under objects) were still being created with no group write permission, hence only the person who committed them could push into the repository.

    We fixed this by setting the umask of the SSH users to 002 with an appropriate group shared by all users.


    umask 002

    where the middle 0 is allowing group write by default.

    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


    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

    Try to do following:

    Go to your Server

        cd rep.git
        chmod -R g+ws *
        chgrp -R git *
        git config core.sharedRepository true

    Then go to your working copy(local repository) and repack it by git repack master

    Works perfectly to me.

    you can using this

    sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"
    sudo su root
    chown -R user:group dir

    The dir is your git repo.

    Then do:

    git pull origin master

    You’ll see changes about commits by others.

    I was getting this error because every time a user push some content, the group of the file changed to the user. And then if some other user tried to push into the repository, it caused permission error and the push was rejected. So one need to ask your sysadmin to change the settings of the repository so that group of any file in the repository is not changed for any push by any user.

    To avoid such problem, please ensure that when you initialize your git repository, use the command “git init –shared=group”.

    OK – turns out it was a permissions problem on GitHub that happened during the fork of emi/bixo to bixo/bixo. Once Tekkub fixed these, it started working again.

    Since the error deals with permissions on the object folder, I did a chown directly on the objects folder and it worked for me.

    This works:

    sudo chmod -R gituser.gituser objects

    I guess many like me ends up in forums like this when the git problem as described above occoures. However, there are so many causes that may lead to the problem that I just wanna share what caused my troubles for others to learn as I already learned from above.

    I have my repos on a Linux NAS from sitecom (Never buy NAS from Sitecom, pleeaaase). I have a repo here that is cloned on many computers but which I suddenly was denied pushing to. Recently I installed a plugin so that my NAS could stand as a squeezebox server.

    This server scans for media to share. What I did not know was that, possible because of a bug, the server changes the user and group setting to squeeze:user for all files it looks into. And that is ALL files. Thus altering the rights I had to push.

    Server is gone and proper rights settings are re-established and everything works perfectly.

    I used

    chmod -R g+ws *
    chown -R <myuser>:<mygroup> *

    Where myuser and mygroup off-course must be replaced with proper settings for your system. try git:git or gituser:gituser or something else you might like.,

    Check the repository:
    $ git remote -v

    origin  ssh:// (fetch)
    origin  ssh:// (push)

    Note that there is a ‘git@’ substring here, it instructs git to authenticate as username ‘git’ on the remote server. If you omit this line, git will authenticate under different username, hence this error will occur.

    In my case there were no unified authentication (e. g. within the domain + AD-like service) between my machine and git virtual server. Therefore git users and group are local for the virtual server. In my case my remote user (which I use to login into remote server) was just not added into remote git group.

    ssh root@<remote_git_server>
    usermod -G <remote_git_group> <your_remote_user>

    After that check the permissions like it’s described in the posts above…

    Have you try sudo git push -u origin –all? Sometimes it’s the only thing you need to avoid this problem. It asks you for the admin system password – the one you can make login to your machine -, and that’s what you need to push – or commit, if it is the case.

    Set permissions in your project:

    sudo chmod -R 777 .git/
    Git Baby is a git and github fan, let's start git clone.