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

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

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

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

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

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

sudo git commit -m "message"

然后再输入密码

git commit -m "message"

修复权限

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

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.

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

问题自动解决了。

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

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

/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中)