Linux git: can't push (unpacker error) 与权限问题相关

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

提问by Max Williams

I have this problem when i try to push in git:

当我尝试推送 git 时遇到了这个问题：

error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://<repo url>/<repo dir>
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://<repo url>/<repo dir>'

I've had this before sporadically and we've always had to solve it by each user sshing to the repo and setting group permissions on all the files therein with

我以前偶尔遇到过这个问题，我们总是不得不通过每个用户 SSH 到 repo 并设置其中所有文件的组权限来解决它

chmod -R g+w *

This was never a satisfactory solution and now it's bitten us in the arse as one of the guys is away and no-one knows his repo user's password. So, i'm trying to solve it properly.

这从来都不是一个令人满意的解决方案，现在它让我们陷入困境，因为其中一个人不在，没有人知道他的回购用户的密码。所以，我正在努力解决它。

The error seems to occur when someone tries to push up a change that will alter a repo dir that is owned by another user (hence setting the group write option above). I've done a bit of googling around this and have found a couple of solutions being discussed (neither of which worked for me)

当有人尝试推送更改以更改另一个用户拥有的 repo 目录时，似乎会发生该错误（因此设置了上面的组写入选项）。我已经对此进行了一些谷歌搜索，并找到了一些正在讨论的解决方案（其中没有一个对我有用）

1) make sure that the group that the repo dirs are shared with is each users' primary group (i believe that is the case already: each user has only one group so that must be their primary group, right?)

1) 确保与 repo 目录共享的组是每个用户的主要组（我相信情况已经如此：每个用户只有一个组，因此必须是他们的主要组，对吗？）

2) git repo core.sharedRepository setting, as detailed here: Git: Can't push from one computerI changed this but it didn't make any difference. Do i need to reload the config or something to actually effect the change?

2) git repo core.sharedRepository 设置，详见此处：Git：无法从一台计算机推送我更改了此设置，但没有任何区别。我是否需要重新加载配置或其他东西才能真正影响更改？

Here's what my repo config looks like atm:

这是我的 repo 配置 atm 的样子：

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedRepository = all
[receive]
        denyNonFastForwards = True

Grateful for any advice or suggestions! max

感谢您的任何意见或建议！最大限度

回答by Cameron Skinner

I use gitosis for managing this kind of stuff. Gitosis has a single user (usually called "git") that owns all the repositories, and it uses public-key-based access control to each repo. It might not suit your setup but is probably worth checking out (no pun intended).

我使用 gitosis 来管理这类东西。Gitosis 有一个拥有所有存储库的用户（通常称为“git”），并且它对每个存储库使用基于公钥的访问控制。它可能不适合您的设置，但可能值得一试（没有双关语）。

回答by spadeworkers

A simpler way to do this is to add a post-receive script which runs the chmod command after every push to the 'hub' repo on the server. Add the following line to hooks/post-receive inside your git folder on the server:

一种更简单的方法是添加一个 post-receive 脚本，该脚本在每次推送到服务器上的“集线器”存储库后运行 chmod 命令。将以下行添加到服务器上 git 文件夹内的 hooks/post-receive：

chmod -Rf u+w /path/to/git/repo/objects

回答by jpswain

I was having trouble with this too, thinking my remote gitolite-admin was corrupted or something wrong.

我也遇到了这个问题，认为我的远程 gitolite-admin 已损坏或出现问题。

My setup is Mac OS X (10.6.6) laptop with remote Ubuntu 10 server with gitolite.

我的设置是 Mac OS X (10.6.6) 笔记本电脑，带有带有 gitolite 的远程 Ubuntu 10 服务器。

It turned out that the problem was with my localcheckout of gitolite-admin.

结果发现问题出在我本地的 gitolite-admin 结账上。

Despite the "unpack failed" error, it turned out the the problem was local.

尽管出现“解包失败”错误，但事实证明问题出在本地。

I figured this out by checking it out again as gitolite-admin2, making a change, and the pushing.

我通过作为 gitolite-admin2 再次检查它，进行更改和推动来解决这个问题。

Voila! It worked!

瞧！有效！

回答by sjas

In case anyone else is stuck with this: it just means the write permissions are wrong in the repo that you're pushing to. Go and chmod -R it so that the user you're accessing the git server with has write access.

万一其他人对此感到困惑：这仅意味着您要推送到的存储库中的写入权限是错误的。去 chmod -R it 以便您访问 git 服务器的用户具有写访问权限。

http://blog.shamess.info/2011/05/06/remote-rejected-na-unpacker-error/

http://blog.shamess.info/2011/05/06/remote-rejected-na-unpacker-error/

It just works.

它只是有效。

回答by Alastair

It is a permission error. The way that was most appropriate and secure for me was adding users to a supplementary groupthat the repo. is owned by (or vice versa):

这是一个权限错误。对我来说最合适和最安全的方法是将用户添加到repo的补充组中。由（或反之亦然）拥有：

groupadd git
chgrp -R git .git
chgrp -R git ./
usermod -G -a git $(whoami)

回答by cmc

This problem can also occur after Ubuntu upgrades that require a reboot.

需要重新启动的 Ubuntu 升级后也会出现此问题。

If the file /var/run/reboot-requiredexists, do or schedule a restart.

如果文件/var/run/reboot-required存在，请执行或安排重新启动。

回答by Jason Robinson

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 solutionby Ariejan de Vroom. It worked and we were all able to pull and push again.

我遇到了这个错误两周，大多数解决方案都将“chmod -R”作为答案，不幸的是我的 git 存储库（本地/远程/与团队共享）都在 Windows 操作系统上，即使chmod -Rv 显示所有文件都更改为“rwxrwxrwx”，随后的“ls -l”仍将所有文件显示为“rwxr-xr-x”，并且错误重复出现。我最终看到了 Ariejan de Vroom 的这个解决方案。它奏效了，我们都能够再次拉动和推动。

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

附带说明一下，我尝试使用 Windows 的本机文件权限/ACL，甚至将问题用户提升为管理员，但这些似乎都没有帮助。不确定环境是否重要，但它可能对具有类似设置的人有所帮助 - 问题团队成员和远程（Windows Server 2008 R2 Standard），我的本地（Windows 7 VM）。

回答by Hrushikesh

I was getting similar error and please see below how I resolved it.

我遇到了类似的错误，请在下面查看我是如何解决的。

My directory structure: /opt/git/project.git and git user is git

我的目录结构：/opt/git/project.git 和 git 用户是 git

$ cd /opt/git/project.git
$ sudo chown -R git:git .

chown with -R option recursively changes the ownership and and group (since i typed git:git in above command) of the current directory. chown -R is necessary since git changes many files inside your git directory when you push to the repository.

带有 -R 选项的 chown 递归地更改当前目录的所有权和组（因为我在上面的命令中输入了 git:git ）。chown -R 是必要的，因为当您推送到存储库时，git 会更改 git 目录中的许多文件。

回答by Mark E. Hamilton

Where I work we have been using this method on all of our repositories for a few years without any problems (except when we create a new repository and forget to set it up this way):

在我工作的地方，几年来我们一直在所有存储库上使用这种方法，没有任何问题（除非我们创建了一个新存储库并忘记以这种方式进行设置）：

1. Set 'sharedRepository = true' in the config file's '[core]' section.

2. Change the group id of the repository to a group shared by all users who are allowed to push to it:

   chgrp -R shared_group /git/our_repos
   chmod -R g+w /git/our_repos
   

3. Set the setgid bit on all directories in the repository so that new files/directories keep the same group:

   find /git/our_repos -type d -exec chmod g+s {} +
   

4. Add this line to the pre-receive hook in the repository to ensure new file permissions allow group read/write:

   umask 007
   

1. 在配置文件的“[core]”部分设置“sharedRepository = true”。

2. 将存储库的组 id 更改为所有允许推送到它的用户共享的组：

   chgrp -R shared_group /git/our_repos
   chmod -R g+w /git/our_repos
   

3. 在存储库中的所有目录上设置 setgid 位，以便新文件/目录保持相同的组：

   find /git/our_repos -type d -exec chmod g+s {} +
   

4. 将此行添加到存储库中的 pre-receive 挂钩以确保新文件权限允许组读/写：

   umask 007
   

回答by dariush

For what it worth, I had the same problem over my own VPS and it was caused by my low hard disk space on VPS. Confirmed by df -hcommand and after i cleaned up my VPS' hard disk; the problem was gone.

无论如何，我在自己的 VPS 上遇到了同样的问题，这是由于 VPS 上的硬盘空间不足造成的。通过df -h命令确认并在我清理了我的 VPS 的硬盘之后；问题就解决了。

Cheers.

干杯。