修复权限

在你确定并修复了潜在的原因(见下文)后，你会想要修复权限:

cd /path/to/repo/.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

注意，如果你想让每个人都能修改存储库，你不需要chgrp，你需要将chmod更改为sudo chmod -R a+rwX。

如果您不修复根本原因，错误将不断出现，您将不得不一遍又一遍地重新运行上述命令。

根本原因

该错误可能是由以下原因之一引起的:

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.

调试这种情况的一个好方法是，下次发生这种情况时，SSH到远程repo, cd到objects文件夹，并执行ls -al。

如果您看到2-3个文件具有不同的用户:组所有权，那么这就是问题所在。

在过去，我遇到过一些遗留脚本访问我们的git repo，通常意味着不同的(unix)用户最后推送/修改文件，而您的用户没有权限覆盖这些文件。你应该创建一个共享git组，所有启用git的用户都在其中，然后递归地chgrp objects文件夹和它的内容，这样它的组所有权就是共享git组。

您还应该在文件夹上添加一个sticky位，以便在文件夹中创建的所有文件将始终具有git组。

Chmod g+s目录名

更新:我不知道core. sharerepository。很高兴知道这一点，尽管它可能只是做上述工作。

适用于Ubuntu(或任何Linux)

从项目根，

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

你可以通过以下方式说出你的名字和你所在的小组:

# for yourname
whoami
# for yourgroup
id -g -n <yourname>

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

我只是想加入我的解。我在OS X上有一个回购，在一些目录上有根所有权，在其他目录上有Home(这是我的用户目录)，这导致了上面列出的相同错误。

谢天谢地，解决办法很简单。从终端:

sudo chown -R Home projectdirectory

我遇到了同样的问题。阅读这里，我意识到这是文件权限的消息是指。对我来说，解决办法是:

/etc/inetd.d/git-gpv

它以“nobody”用户启动git-daemon，因此缺乏写权限。

# Who   When    What
# GPV   20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV   20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo

(我怀疑其他人把他们的inetd conf文件称为git-gpv。通常它会直接在/etc/inetd.conf中)

在你添加了一些东西之后……提交它们，并在所有完成后推动它!爆炸! !开始所有的问题…正如您应该注意到的，在定义新项目和现有项目的方式上存在一些差异。如果其他人尝试添加/提交/推送相同的文件或内容(git将两者保持为相同的对象)，我们将面临以下错误:

$ 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

要解决这个问题，您必须考虑到操作系统的权限系统，因为在这种情况下您受到了它的限制。为了更好地理解这个问题，继续检查你的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

*注意，这些文件的权限只授予你的用户，没有人可以改变它…＊

Level       u   g   o
Permission rwx r-x ---
Binary     111 101 000
Octal       7   5   0

解决问题

如果你有超级用户权限，你可以继续使用第二步自己更改所有权限，在任何其他情况下，你将需要询问所有用户与他们的用户创建的对象，使用下面的命令来知道他们是谁:

$ ls -la | awk '{print $3}' | sort -u 
<your user_name>
<his user_name>

现在你和所有文件的所有者用户将不得不改变这些文件的权限，做:

$ chmod -R 774 .

之后，你需要添加一个新属性，等价于——shared=group，根据文档，这使存储库组可写，执行:

$ git config core.sharedRepository group

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

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

如果你盲目地遵循[1]上的说明，这可能会发生，因为你可能创建了git-user作为根用户，然后立即转移到git init，而没有改变用户。

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

您需要对要推入的目录具有足够的写权限。

在我的例子中:Windows 2008服务器

右键单击git回购目录或父目录。

属性>共享选项卡>高级共享>权限>确保用户具有适当的访问权限。

对我来说，这些建议都没用。我在Windows上，这对我来说很有效:

将远程回购复制到另一个文件夹中 共享文件夹并授予适当的权限。 确保您可以从本地计算机访问该文件夹。 将此回购添加为本地回购中的另一个远程回购。(git remote add foo //SERVERNAME/path/to/ replicated /git) Push到foo。Git push foo master。有用吗?太棒了!现在删除not-working repo并将其重命名为之前的任何内容。确保权限和共享属性保持不变。

为我解决了… 就在这个:

sudo chmod 777 -R .git/objects

sudo chmod -R ug+w .;

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

Linux、macOS:

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

其中name是用户名，group是用户名所属的组。

使用下面的命令，就像魔术一样

sudo chown -R "${USER:-$(id -un)}" .

准确地输入命令(在结尾有额外的空格和一个点)

命令分解

sudo

以root用户运行

chown

改变所有权

-R

针对所有文件和文件夹的递归操作

"${USER:-$(id -un)}"

从$ user中获取用户名，如果没有设置，则通过运行id -un获取值

.

定位当前目录

也有可能您添加了另一个具有相同别名的本地存储库。例如，您现在有两个本地文件夹称为origin，因此当您尝试推送时，远程存储库将不接受您的凭据。

重命名本地存储库别名，您可以通过这个链接https://stackoverflow.com/a/26651835/2270348

也许您可以留下一个您喜欢的本地存储库作为origin，而其他存储库则重命名它们，例如从origin到另一个origin。记住，这些只是别名，你所需要做的就是记住新的别名和它们各自的远程分支。

对我有用

sudo chmod -R g+rwX .

当我进入Rstudio项目时，我得到了这个。我意识到我忘了做:

sudo rstudio

程序启动时。事实上，我有另一个bug，我需要做的是:

sudo rstudio --no-sandbox

我在Samba共享上的远程存储库遇到了这个问题;我成功地从这个遥控器上拉了出来，但在推它的时候失败了。

错误的原因是我的~/中的凭据不正确。smbcredentials文件。

最简单的解决方案是:

来自项目总监:

sudo chmod 777 -R .git/objects

在使用git很长一段时间没有问题之后，我今天遇到了这个问题。经过一些思考，我意识到我今天早些时候把我的面具从022换成了别的东西。

其他人的所有答案都是有帮助的，例如，对有问题的目录执行chmod。但根本原因是我的新umask，每当在.git/object/下创建一个新目录时，它总是会导致一个新问题。所以，对我来说，长期的解决方案是把umask改回022。

我将补充我的意见，作为一种发现目录中具有特定所有权的文件的方法。

该问题是由于以根用户身份运行某些git命令引起的。 收到的信息是:

$ git commit -a -m "fix xxx"
error: insufficient permission for adding an object to repository database .git/objects
error: setup.sh: failed to insert into database

我首先查看了git config -l，然后我解决了:

find .git/ -exec stat --format="%G %n" {} + |grep root

chown -R $(id -un):$(id -gn) .git/objects/

git commit -a -m "fixed git objects ownership"

我在使用Vagrant运行远程开发开发机器时得到了这个错误。上述解决方案都不能工作，因为所有文件都具有正确的权限。

我把config.vm.box = "hasicorp/ bioniic64 "改为config.vm.box = "bento/ubuntu-20.10"。

在我的例子中，解决方案就是git再次提交。

问题自动解决了。

发生了什么事?我使用^C (Control-C)来避免写错误的提交消息。(我从错误的剪贴板中粘贴了错误的消息。)因此，我假设进程暂时冻结在后台，这暂时锁定了数据库。

只需复制并粘贴到您自己的终端。

sudo chown -R "${USER:-$(id -un)}" .

我通过使用ssh://基于URL而不是基于http://的URL解决了这个问题。

几天前，我使用基于http://的URL克隆了存储库。在克隆和推送之间，我不得不在我的帐户上启用2FA，随后将我的公钥添加到代码库中。

由于启用了2FA, http:// URL无法正常工作。

您需要在您的终端上复制并粘贴此命令:-

sudo chmod 777 -R .git/objects

确保以admin身份打开命令行提示符。然后，确保项目文件不是只读的。

在windows中，您可以通过右键单击项目文件夹来检查->单击“显示更多选项”->单击“属性”->取消选择“只读”->单击“应用”

我遇到这个问题太多次了，但每次发生时，我都尝试使用sudo命令推送或提交，在输入密码后，我不使用sudo推送或提交 例如

sudo git commit -m "message"

然后再输入密码

git commit -m "message"

我只是尝试了sudo git commit -m“XY”，然后我用CTRL + C取消了它，然后再次尝试git commit -m“XY”，然后它突然工作了。

修复权限

我用这个来修复我的。git文件夹，@richard-hansen的答案缺少用户。

首先，您需要进入.git文件夹。

cd /path/to/repo/.git

然后执行这些命令。

sudo chown -R user:groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

这也将修复所有子模块。

这个问题还有一个解决方案，当你使用多个正在运行的docker容器并尝试更改和提交/推送一些东西时，这个解决方案可以重现。

在我的情况下，我不能提交任何东西，而所有的容器都在那里。但一旦我杀了他们，我就能毫无问题地投入。

我没有研究这种行为的原因，但我可以猜到，您在本地更改的代码在docker容器中重用，因为它是从根用户运行的，因此它可以更改它所使用的文件的一些权限-这可能会导致问题。