当我尝试推到共享git远程时,我得到以下错误: 向存储库数据库添加对象权限不足

这适用于下一次推送,因为所有的文件都属于正确的组,但下一次有人推送一个更改时,它会在对象文件夹中创建一个新项目,该项目的默认组为组。我唯一能想到的就是改变所有开发人员签入项目的默认组,但这似乎是一种hack。什么好主意吗?谢谢。


当前回答

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

该问题是由于以根用户身份运行某些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"

其他回答

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

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

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

对我有用

sudo chmod -R g+rwX .

修复权限

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

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)来避免写错误的提交消息。(我从错误的剪贴板中粘贴了错误的消息。)因此,我假设进程暂时冻结在后台,这暂时锁定了数据库。