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


591

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

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


Я получил эту ошибку после того, как случайно git addи git commit-ing от имени пользователя root. Я исправил это с помощью git resetответа на этот вопрос, чтобы исправить .gitправа доступа к каталогу.
StockB

Как я могу узнать, какой объект он пытался создать (при ручной отладке таких проблем с разрешениями)? Сообщение об ошибке слишком расплывчато.
Мирабилось

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

Ответы:


864

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

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

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

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

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

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

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

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

1
@ Ричард Хансен - Я действительно не знаю, что вы имеете в виду под принуждением к владению. Я смотрю на человека для chmod, но не знаю достаточно об этом, чтобы слова имели смысл :) Любые советы?
Сказ

7
@GiH: вы ничего не получите, если он не установлен (что совпадает с falseили umask). Смотрите git help configдля более подробной информации.
Ричард Хансен

10
Я должен был выдать git pushс использованием учетной записи root в моем рабочем каталоге. Я обнаружил, что владельцем некоторых файлов репозитория git является root ( -r--r--r--. 1 root root 6380 5月 25 12:39 9b44bd22f81b9a8d0a244fd16f7787a1b1d424) согласно этому ответу.
LiuYan 研 研

3
@MattBrowne: обратите внимание, что это прописная Xбуква, а не строчная x. Прописная буква Xозначает «установить, S_IXGRPесли файл является каталогом (или если установлен любой другой S_IX*бит)», поэтому он не сделает все файлы исполняемыми. Это может быть ненужным, но, возможно, нет, если core.sharedRepositoryбыло установлено 0600в какой-то момент в прошлом.
Ричард Хансен

2
@francoisromain: эта строка устанавливает бит setgid для всех каталогов. См. Gnu.org/software/coreutils/manual/html_node/…
Ричард Хансен

440

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

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

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

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

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


7
Работал отлично! Да, по некоторым причинам некоторым папкам было присвоено другое имя и группа (root).
Петр Арандоренко

2
Я получаю:Sorry, user myuser is not allowed to execute '/bin/chown
Франциско Корралес Моралес

*Вся разница. Спасибо.
Брэдли Флад

5
Моя проблема была я когда - то сделал «Git тянуть» , как корень, который я думаю , что облажался разрешения ... вы можете проверить, выполнивls .git
rogerdpack

Спасибо за быстрое решение!
Helvete

75

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

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

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


6
Работает как шарм!
Донкадавона

1
классно! отлично работал на моем Mac
Sachin

Это тоже помогло мне! Спасибо.
Хорват Адам

Действительно, работал как по волшебству! Спасибо!
Кумар Маниш

49

sudo chmod -R ug+w .;

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


2
Это то, что сработало для меня. К сожалению, принятый ответ не сделал. Спасибо, Раджендра!
наслаждайтесь

27

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

К счастью, решение было простым. С терминала:

sudo chown -R Home projectdirectory

Со мной случилось то же самое. Я не могу понять, как некоторые объекты получили права root, но они сделали это.
vy32

18

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

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

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

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

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

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


15

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

sudo chmod 777 -R .git/objects

21
Chmod 777не рекомендуется, так как все ваши файлы открыты для остального мира, что делает вашу машину уязвимой
Елена

23
Если ваш совет таков chmod 777, в 99 случаях из 100 вы не понимаете проблему, и вы, вероятно, вызовете больше проблем, чем решите. Как показывает принятый ответ выше, этот вопрос не отличается.
Джонатан

Почему вы, ребята, не предлагаете приемлемый ответ, а говорите, что это неправильный выбор?
Джовани

2
Потому что, хотя на странице есть приемлемые ответы, этот неприемлемый ответ все еще здесь.
Teh JOE

sudo chmod -R 777 .git / objects
Набиэль Ахмед

9

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

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

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


7

Linux, macOS:

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

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


5

После того, как вы добавите некоторые вещи ... зафиксируйте их и после того, как закончите, нажмите на них 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


У меня было все то же самое username:groupnameдля моего, но когда я попытался chmod -R 774 ., я мог тогда бежать git add --allуспешно.
Джон Скилбек

3

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

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

1
В моем случае, просто скопировав локальную папку в новую папку, удалив старую и переименовав новую в старое, исправили проблемы с разрешениями.
Мгиуфрида

2

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

/etc/inetd.d/git-gpv

Он запускал git-daemon, поскольку пользователь « 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

(Я сомневаюсь, что другие называют их conf-файлом inetd git-gpv. Обычно это будет прямо в /etc/inetd.conf)


1

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

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

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

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



1

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

Переименуйте псевдонимы локального репозитория, вы можете перейти по этой ссылке https://stackoverflow.com/a/26651835/2270348

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



0

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

sudo rstudio

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

sudo rstudio --no-sandbox

0

Использовать sudo для коммита -m

  • git add -A
  • sudo git commit -m "Использовать sudo для коммита -m"
  • git push origin branch_name

0

Я получал эту проблему с удаленным репозиторием на общем ресурсе Samba; Я успешно вытащил из этого пульта, но не смог при нажатии на него.

Причиной ошибки были неверные учетные данные в моем ~/.smbcredentialsфайле.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.