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 To [email protected]:bixo/bixo.git ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to '[email protected]:bixo/bixo.git'
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?
Since the error deals with permissions on the object folder, I did a chown directly on the objects folder and it worked for me.
you can using this
sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"
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
ssh://[email protected]/~git/repo.git
Unfortunately I stored a putty session with the name example.com which was configured to login as user myOtherUser.
So, while I thought git connects to the host example.com with the User 'git', Git/TortoiseGit has connected to the putty session example.com 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 example.com to [email protected]
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.
e.g.
umask 002
where the middle 0 is allowing group write by default.
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".
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.
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.
Check the repository: $ git remote -v
origin ssh://[email protected]:2283/srv/git/repo.git (fetch)
origin ssh://[email protected]:2283/srv/git/repo.git (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.
sudo chmod 777 -R .git/objects
This works:
sudo chmod -R gituser.gituser objects
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.
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...
When you see this error outside of github, here's a remedy.
Got this from: http://mapopa.blogspot.com/2009/10/git-insufficient-permission-for-adding.html
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.
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.
user@M063:/var/www/html/app/.git/objects$ sudo chmod 777 -R .git/objects
user@M063:/var/www/html/app/.git/objects$ sudo chown -R user:user .git/objects/
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
chmod should be chown, so the correct line is:
sudo chown -R gituser:gituser 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.
Example:
If your user is called "git", his group "gitgroup", and the location of the Git repo is: [email protected]:path/to/repo.git
then do a:
sudo chown -R git:gitgroup path/to/repo.git/
This fixed the git insufficient permission error for me.
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.
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.,
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.
Source: Stackoverflow.com