Git: Can't Push (Unpacker Error) Related to Permission Issues

git: can't push (unpacker error) related to permission issues

I had this error for two weeks, and the majority of the solutions stated 'chmod -R' as the the answer, unfortunately for me my git repos (local / remote / shared - with team) were all on Windows OS, and even though chmod -Rv showed all the files changed to 'rwxrwxrwx', a subsequent 'ls -l' still showed all files as 'rwxr-xr-x' and the error repeated itself. I eventually saw this solution by Ariejan de Vroom. It worked and we were all able to pull and push again.

On both local (the local that is having trouble pushing) and remote repos, run the following commands:

$ git fsck
$ git prune
$ git repack
$ git fsck

On a side note, I tried using Windows' native file permissions / ACL and even resorted to elevating the problem user to Administrator, but none of that seemed to help. Not sure if the environment is important, but it may help someone with a similar setup - problem team member and remote (Windows Server 2008 R2 Standard), my local (Windows 7 VM).

Git: Can't push from one computer

I'm not a windows user so I'm stabbing in the dark a little here. It looks like the remote file system is mounted and you're just pushing to that (not using ssh:// or git://). Is that FS somehow mounted readonly? Can he create/modify files on there (outside of git)?

Git push failed - unpack-objects abnormal exit

According to this article git repack remote/origin/master might help in case your local repository was corrupted. To check that you can try cloning your remote repo into new directory and test push from it.

Git Error: remote unpack failed: unable to create temporary object directory - While attempting to push to remote repository

Somewhat same problem. Solved it (for me). A tricky one.

My client is a MacOS. I have it running under user 'president'.

My git-server runs on a Synology NAS. There I am majorly running everything also under a user called 'president'. In fact these are not the same users since they exist on different physical setups.

And by the way I setup the git-server with a user named 'gituser'. Since the 'president' is a very mighty user there is no problem to access everything with 'president' which can be accessed by 'gituser'.

And now, since I am remotely accessing with a local user with the same name that the server somewhat knows this is why I worked.

In other words this worked after password is asked and entered:

CLIENT/president> git clone ssh://myserver:22/git/myrepo

The login happens with (the wrong) 'president' and (some) git functionality will work flawless.

The better way is using the proper git-user 'gituser' which is allocated on the server:

CLIENT/president> git clone ssh://gituser@myserver:22/git/myrepo

That does the trick for me. So no corrections need to be done on the server side.

Further reading on setting up git on a Synology: https://gist.github.com/walkerjeffd/374750c366605cd5123d

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

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.

---

Related Topics