Git Ошибка Push: недостаточное разрешение для добавления объекта в базу данных репозитория

Когда я пытаюсь нажать на общий пульт git, я получаю следующую ошибку: insufficient permission for adding an object to repository database

Затем я прочитал об исправлении здесь: Fix Это сработало для следующего нажатия, поскольку все файлы были правильной группы, но в следующий раз, когда кто-то подтолкнул изменение, он сделал новый элемент в папке объектов, в которой группа по умолчанию была группой. Единственное, что я могу придумать, это изменить всю группу разработчиков по умолчанию для элементов, которые они проверяют, но это похоже на взлома. Есть идеи? Спасибо.

ОТВЕТЫ

Ответ 1

Разрешения на ремонт

После того, как вы определили и устранили основную причину (см. Ниже), вы захотите восстановить разрешения:

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

Обратите внимание: если вы хотите, чтобы все могли изменять репозиторий, вам не нужен chgrp и вы захотите изменить chmod на sudo chmod -R a+rwX.

Если вы не исправите основную причину, ошибка продолжит возвращаться, и вам придется снова и снова повторять -R отмену вышеуказанных команд.

Основные причины

Ошибка может быть вызвана одним из следующих:

  • Репозиторий не настроен для использования в качестве общего репозитория (см. core.sharedRepository в git help config). Если на выходе:

    git config core.sharedRepository

    не является group или true или 1 или какой-то маской, попробуйте выполнить:

    git config core.sharedRepository group

    а затем повторно -R un рекурсивные 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 находятся в одной группе, которая владеет каталогами репозитория. Убедитесь, что владелец группы в каталогах указан правильно и что все пользователи находятся в этой группе.

Ответ 2

Для Ubuntu (или любого Linux)

Из корня проекта

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

Вы можете указать, что должно быть у вашего имени и вашей группы, посмотрев разрешения на большую часть вывода из этой команды ls -al

Примечание: помните звезду в конце строки sudo

Ответ 3

sudo chmod -R ug+w .;

В принципе, файл .git/objects не имеет разрешений на запись. Вышеупомянутая строка предоставляет разрешение всем файлам и папкам в каталоге.

Ответ 4

используйте следующую команду, работает как magic

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

введите команду точно так, как она есть (с дополнительными пробелами и одной точкой в ​​конце)

Ответ 5

Я просто хотел добавить свое решение. У меня было репо на OS X, у которого было право на root в некоторых каталогах и Home (это мой каталог пользователей) на других, которые вызвали ту же ошибку, что и выше.

Решение было просто благодарно. От терминала:

sudo chown -R Home projectdirectory

Ответ 6

Хороший способ отладки - это в следующий раз, когда это произойдет, SSH в удаленное репо, cd в папку с объектами и выполните ls -al.

Если вы видите 2-3 файла с разными правами пользователя: группа, то это проблема.

В прошлом мне случалось, что некоторые устаревшие скрипты обращались к нашему репозиторию git и обычно означает, что другой (unix) пользователь вставлял/модифицировал файлы последним, и у вашего пользователя нет разрешений на перезапись этих файлов. Вы должны создать общую группу git, в которой находятся все git -enabled пользователи, а затем рекурсивно chgrp папка objects, и это содержимое, так что это групповое владение является общей группой git.

Вы также должны добавить липкий бит в папку, чтобы все файлы, созданные в папке, всегда имели группу git.

chmod g + s имя-каталога

Обновление: я не знал о core.sharedRepository. Полезно знать, хотя он, вероятно, просто делает это.

Ответ 7

Решенный для меня... только это:

sudo chmod 777 -R .git/objects

Ответ 8

Это может произойти, если вы запустили git init с другим пользователем из того, который вы планируете использовать при нажатии изменений.

Если вы слепо следуете инструкциям в [1], это произойдет, поскольку вы, вероятно, создали git -user как root, а затем сразу же перешли к git init без изменения пользователя между ними.

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

Ответ 9

После того, как вы добавите некоторые вещи... зафиксируйте их и после того, как закончите, нажмите на них! BANG !! Начните все проблемы... Как вы должны заметить, существуют некоторые различия в способах определения как новых, так и существующих проектов. Если какой-то другой человек попытается добавить/зафиксировать/отправить те же файлы или содержимое (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

Ответ 10

Linux, macOS:

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

где name - ваше имя пользователя, а group - это группа, к которой принадлежит ваше имя пользователя.

Ответ 11

В моем случае ни один из предложений не работал. Я нахожусь в Windows, и это сработало для меня:

  • Копирование удаленного репо в другую папку
  • Разделите папку и укажите соответствующие разрешения.
  • Убедитесь, что вы можете получить доступ к папке с локальной машины.
  • Добавьте это репо в качестве другого удаленного репо в вашем локальном репо. (git remote add foo //SERVERNAME/path/to/copied/git)
  • Нажмите на foo. git push foo master. Это сработало? Большой! Теперь удалите нерабочее репо и переименуйте его во все, что было раньше. Удостоверьтесь, что права и свойство share остаются прежними.

Ответ 12

Я попал в эту же проблему. Прочитав здесь, я понял, что это права на файлы, на которые ссылалось сообщение. Исправление для меня было:

/etc/inetd.d/git -gpv

Он начинал с git -demon как пользователь ' nobody, поэтому не было права на запись.

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

Ответ 13

Вам нужны достаточные права на запись в каталоге, на который вы нажимаете.

В моем случае: сервер Windows 2008

щелкните правой кнопкой мыши каталог git repo или родительский каталог.

Свойствa > вкладка "Общий доступ" > "Расширенный доступ" > "Разрешения" > убедитесь, что у пользователя есть соответствующие права доступа.

Ответ 14

Возможно, вы случайно вложили git-репозитории

Ответ 15

выполните следующую команду для .git:

chmod -R 777 .git

Ответ 16

Также возможно, что вы добавили другой локальный репозиторий с тем же псевдонимом. Например, теперь у вас есть 2 локальные папки, называемые origin поэтому при попытке отправки удаленный репозиторий не примет ваши учетные данные.

Переименуйте псевдонимы локального репозитория, вы можете перейти по этой ссылке fooobar.com/questions/18602/...

Возможно, вы можете оставить 1 локальный репозиторий по своему вкусу как origin а другие переименовать их, например, из origin в anotherorigin. Помните, что это просто псевдонимы, и все, что вам нужно сделать, это запомнить новые псевдонимы и их соответствующие удаленные ветки.

Ответ 17

Я получаю эту ошибку при попытке проталкивания через среду IDE (в данном случае PHPStorm). Когда я пытался использовать терминал (OSX), он работает! Таким образом, это явно проблема разрешения. Хотя я не могу найти, как навсегда исправить его, используя

$ sudo git push origin master

выполнит трюк

Ответ 18

Работает для меня

sudo chmod -R g+rwX .

Ответ 19

Я получил это при подключении к проекту Rstudio. Я понял, что забыл сделать:

sudo rstudio

при запуске программы. На самом деле, поскольку у меня есть еще одна ошибка, мне нужно сделать:

sudo rstudio --no-sandbox