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. Compre
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 chmod 777 -R .git/objects
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://git@example.com/~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 myOtherUse@example.com
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.
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.
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...