Git Push Error: insufficient permission for adding

问题:

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.

回答1:

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

回答2:

For Ubuntu (or any Linux)

From project root,

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

You can tell what yourname and yourgroup should be by looking at the permissions on the majority of the output from that ls -al command

Note: remember the star at the end of the sudo line

回答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.

回答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

回答5:

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.

回答6:

Solved for me... just this:

sudo chmod 777 -R .git/objects

回答7:

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)

回答8:

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

回答9:

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

https://coderwall.com/p/8b3ksg

回答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.

回答11:

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.

回答12:

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)

回答13:

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.

回答14:

You may have accidentally nested git repositories

回答15:

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.