Git 推送错误：将对象添加到存储库数据库的权限不足

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

提问by skaz

When I try to push to a shared git remote, I get the following error: insufficient permission for adding an object to repository database

当我尝试推送到共享 git 远程时，出现以下错误： insufficient permission for adding an object to repository database

Then I read about a fix here: FixThis 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.

然后我在这里阅读了一个修复程序：FixThis 适用于下一次推送，因为所有文件都属于正确的组，但是下次有人推送更改时，它在具有默认组的对象文件夹中创建了一个新项目作为组。我唯一能想到的是更改他们签入的项目的所有开发人员的默认组，但这似乎是一个黑客。有任何想法吗？谢谢。

回答by Richard Hansen

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 chgrpand you will want to change the chmod to sudo chmod -R a+rwX .

请注意，如果您希望每个人都能够修改存储库，则不需要chgrp并且您需要将 chmod 更改为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.sharedRepositoryin git help config). If the output of:

  git config core.sharedRepository
  

  is not groupor trueor 1or some mask, try running:

  git config core.sharedRepository group
  

  and then re-run the recursive chmodand 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.sharedRepositoryis trueor 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 chmodor chownto 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.

• 存储库未配置为共享存储库（参见core.sharedRepository参考资料git help config）。如果输出：

  git config core.sharedRepository
  

  不是group或true或1或某些掩码，请尝试运行：

  git config core.sharedRepository group
  

  然后重新运行递归chmod和chgrp（参见上面的“修复权限”）。

• 操作系统不会将目录上的 setgid 位解释为“所有新文件和子目录都应该继承组所有者”。

  当core.sharedRepository是true或 时group，Git 依赖于 GNU 操作系统（例如，每个 Linux 发行版）的特性来确保新创建的子目录归正确的组（所有存储库用户所在的组）所有。此功能记录在GNU coreutils 文档中：

  ... [如果] 一个目录的 set-group-ID 位被设置，新创建的子文件继承与目录相同的组，新创建的子目录继承父目录的 set-group-ID 位。... [此机制让] 用户更轻松地共享文件，减少使用chmod或chown共享新文件的需要。

  然而，并不是所有的操作系​​统都有这个特性（NetBSD 就是一个例子）。对于这些操作系统，您应该确保所有 Git 用户都具有相同的默认组。或者，您可以通过运行来使存储库成为全球可写的git config core.sharedRepository world（但要小心——这不太安全）。

• 文件系统不支持 setgid 位（例如，FAT）。ext2、ext3、ext4 都支持 setgid 位。据我所知，不支持 setgid 位的文件系统也不支持组所有权的概念，因此所有文件和目录无论如何都将归同一个组所有（哪个组是挂载选项）。在这种情况下，请确保所有 Git 用户都在拥有文件系统中所有文件的组中。
• 并非所有 Git 用户都在拥有存储库目录的同一组中。确保目录上的组所有者正确并且所有用户都在该组中。

回答by TerryS

For Ubuntu (or any Linux)

对于 Ubuntu（或任何 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

您可以通过查看该 ls -al 命令的大部分输出的权限来判断 yourname 和 yourgroup 应该是什么

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

注意：记住 sudo 行末尾的星号

回答by Code_Worm

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)

完全按原样输入命令（在末尾有额外的空格和一个点）

回答by Rajendra kumar Vankadari

sudo chmod -R ug+w .;

sudo chmod -R ug+w .;

Basically, .git/objectsfile does not have write permissions. The above line grants permission to all the files and folders in the directory.

基本上，.git/objects文件没有写权限。上面的行授予对目录中所有文件和文件夹的权限。

回答by Brandon

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.

我只是想添加我的解决方案。我在 OS X 上有一个 repo，它在某些目录上拥有 root 的所有权，而在其他目录上拥有 Home（这是我的用户目录），这导致了上面列出的相同错误。

The solution was simple thankfully. From terminal:

谢天谢地，解决方案很简单。从终端：

sudo chown -R Home projectdirectory

回答by Mauvis Ledford

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.

调试这种情况的一个好方法是下次发生这种情况时，通过 SSH 进入远程仓库，cd 进入对象文件夹并执行ls -al.

If you see 2-3 files with different user:group ownership than this is the problem.

如果您看到 2-3 个具有不同 user:group 所有权的文件，这就是问题所在。

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 chgrpthe objectsfolder and it's contents so that it's group ownership is the shared gitgroup.

过去发生在我身上，一些遗留脚本访问我们的 git 存储库，通常意味着不同的（unix）用户最后推送/修改文件，而您的用户没有覆盖这些文件的权限。您应该创建一个共享的git组所有启用git的用户都在，然后递归chgrp的objects文件夹，它的内容，以便它的组所有权是共享git组。

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.

您还应该在文件夹上添加一个粘性位，以便文件夹中创建的所有文件始终具有git.

chmod g+s directory-name

chmod g+s 目录名

Update: I didn't know about core.sharedRepository. Good to know, though it probably just does the above.

更新：我不知道 core.sharedRepository。很高兴知道，虽然它可能只是做上述。

回答by GUSTAVO BERBERT

Solved for me... just this:

为我解决了......就是这样：

sudo chmod 777 -R .git/objects

回答by gitzor

This can easily happen if you ran git initwith a different user from the one you are planning to use when pushing changes.

如果您git init在推送更改时与计划使用的用户不同，则很容易发生这种情况。

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] 上的说明，这将会发生，因为你可能以 root 身份创建了 git-user，然后立即转移到 git init 而没有在两者之间更改用户。

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

回答by Afshin Mehrabani

Linux, macOS:

Linux、macOS：

cd .git/
sudo chown -R name:group *

where nameis your username and groupis the group that your username belongs to.

哪里name是您的用户名，group是您的用户名所属的组。

回答by helmedeiros

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 keep both as同一个对象），我们将面临以下错误：

$ 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:

要解决这个问题，您必须考虑操作系统的权限系统，因为在这种情况下您会受到它的限制。你更好地理解了这个问题，继续检查你的 git 对象的文件夹 (.git/objects)。你可能会看到类似的东西：

<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 }' | 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:

之后，您需要为新存储库添加一个等效于 --shared=group done 的新属性，根据文档，这使存储库可写，执行：

$ git config core.sharedRepository group

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

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