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

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?

Solution

Repair Permissions

After you have identified and fixed the underlying cause (see below), you'll want to repair the permissions:

cd /path/to/repo/.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

Note if you want everyone to be able to modify the repository, you don't need the chgrp and you will want to change the chmod to sudo chmod -R a+rwX .

If you do not fix the underlying cause, the error will keep coming back and you'll have to keep re-running the above commands over and over again.

Underlying Causes

The error could be caused by one of the following:

The repository isn't configured to be a shared repository (see core.sharedRepository in git help config). If the output of:
```
 git config core.sharedRepository
```
is not group or true or 1 or some mask, try running:
```
 git config core.sharedRepository group
```
and then re-run the recursive chmod and chgrp (see "Repair Permissions" above).
The operating system doesn't interpret a setgid bit on directories as "all new files and subdirectories should inherit the group owner".

When core.sharedRepository is true or group, Git relies on a feature of GNU operating systems (e.g., every Linux distribution) to ensure that newly created subdirectories are owned by the correct group (the group that all of the repository's users are in). This feature is documented in the GNU coreutils documentation:

... [If] a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. ... [This mechanism lets] users share files more easily, by lessening the need to use chmod or chown to share new files.

However, not all operating systems have this feature (NetBSD is one example). For those operating systems, you should make sure that all of your Git users have the same default group. Alternatively, you can make the repository world-writable by running git config core.sharedRepository world (but be careful—this is less secure).
The file system doesn't support the setgid bit (e.g., FAT). ext2, ext3, ext4 all support the setgid bit. As far as I know, the file systems that don't support the setgid bit also don't support the concept of group ownership so all files and directories will be owned by the same group anyway (which group is a mount option). In this case, make sure all Git users are in the group that owns all the files in the file system.
Not all of the Git users are in the same group that owns the repository directories. Make sure the group owner on the directories is correct and that all users are in that group.