Помилка Git Push: недостатній дозвіл на додавання об’єкта до бази даних сховища

Коли я намагаюся натиснути на загальний git віддалений, я отримую таку помилку: insufficient permission for adding an object to repository database

Тоді я прочитав тут про виправлення тут: Виправлення. Це працювало для наступного натиску, оскільки всі файли були належної групи, але наступного разу, коли хтось натиснув на зміну, він зробив новий елемент у папці об'єктів, яка мала свою групу за замовчуванням. як група. Єдине, про що я можу придумати, - це змінити всю групу розробників за замовчуванням на елементи, в які вони зареєстровані, але це здається злому. Будь-які ідеї? Дякую.

Ремонт дозволів

Після виявлення та виправлення основної причини (див. Нижче), вам потрібно буде відновити дозволи:

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 .

Якщо ви не усунете основну причину, помилка продовжуватиметься повертатися, і вам доведеться знову і знову виконувати вищезазначені команди.

Основні причини

Помилка може бути викликана одним із наступних:

• Репозиторій не налаштований як спільне сховище (див. core.sharedRepositoryВ git help config). Якщо вихід:

  git config core.sharedRepository
  

  НЕ groupабо trueабо 1або який - або маски, спробуйте запустити:

  git config core.sharedRepository group
  

  а потім повторно запустіть рекурсивний chmodі chgrp(див. "Ремонт дозволів" вище).

• Операційна система не інтерпретує встановлений жорсткий біт у каталогах як "всі нові файли та підкаталоги повинні успадковувати власника групи".

  Коли core.sharedRepositoryє trueабо group, Git покладається на функцію операційних систем GNU (наприклад, кожен дистрибутив Linux), щоб переконатися, що новостворені підкаталоги належать правильній групі (групі, в якій знаходяться всі користувачі репозиторію). Ця особливість задокументована в документації на GNU coreutils :

  ... [Якщо] встановлено біт ідентифікатора set-group для каталогу, новостворені підфайли успадковують ту ж групу, що і каталог, а новостворені підкаталоги успадковують біт батьківського каталогу set-group-ID. ... [Цей механізм дозволяє] користувачам ділитися файлами легше, зменшуючи потребу у використанні chmodабо спільному використанні chownнових файлів.

  Однак не всі операційні системи мають цю особливість (NetBSD - один із прикладів). Для цих операційних систем слід переконатися, що всі ваші користувачі Git мають однакову групу за замовчуванням. Крім того, ви можете зробити сховище в світі для запису, запустивши git config core.sharedRepository world(але будьте обережні - це менш безпечно).

• Файлова система не підтримує встановлений жорсткий біт (наприклад, FAT). ext2, ext3, ext4 всі підтримують встановлений жорсткий біт. Наскільки я знаю, файлові системи, які не підтримують встановлений біт, також не підтримують концепцію власності групи, тому всі файли та каталоги так чи інакше будуть належати одній групі (яка група - це варіант монтажу). У цьому випадку переконайтесь, що всі користувачі Git належать до групи, яка володіє всіма файлами у файловій системі.
• Не всі користувачі Git належать до тієї ж групи, яка володіє каталогами репозиторію. Переконайтесь, що власник групи в каталогах правильний і що всі користувачі в цій групі.

Для Ubuntu (або будь-якого Linux)

З кореня проекту,

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

Ви можете сказати, яким має бути ваше ім’я та ваша група, переглянувши дозволи на більшість результатів із цієї команди ls -al.

Примітка: пам’ятайте про зірку в кінці лінії судо

використовувати наступну команду, працює як магія

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

введіть команду точно так, як є (з додатковими пробілами та однією крапкою в кінці)

sudo chmod -R ug+w .;

Фактично, .git/objectsфайл не має дозволу на запис. Наведений вище рядок надає дозвіл на всі файли та папки в каталозі.

Я просто хотів додати своє рішення. У мене була репо в OS X, яка мала власність root на деякі каталоги та Home (що є моїм каталогом користувачів) на інші, що спричинило ту саму помилку, перелічену вище.

Рішення було на щастя простим. Від терміналу:

sudo chown -R Home projectdirectory

Хороший спосіб налагодження цього питання - це наступного разу, коли SSH перейде у віддалений репост, входить у папку об'єктів і зробить ls -al.

Якщо ви бачите 2-3 файли з іншим користувачем: власність групи, ніж це проблема.

У мене раніше траплялося, коли деякі застарілі сценарії отримують доступ до нашого git repo, і зазвичай це означає, що інший (unix) останній користувач натискає / модифікує файли останнього, і ваш користувач не має дозволу перезаписувати ці файли. Ви повинні створити спільну групу GIT , що всі користувачі GIT-включений в , а потім рекурсивно папку і її вміст , так що це група власності є спільною групою.chgrpobjectsgit

Також слід додати клейкий біт у папці, щоб усі файли, створені в папці, завжди мали групу git.

chmod g + s-ім'я каталогу

Оновлення: я не знав про core.sharedRepository. Добре знати, хоча це, мабуть, саме вищесказане.

Для мене вирішено ... саме так:

sudo chmod 777 -R .git/objects

Це може статися легко, якщо ви працювали git initз іншим користувачем, ніж той, який ви плануєте використовувати під час натискання змін.

Якщо сліпо слідувати інструкціям [1], це станеться, коли ви, ймовірно, створили git-користувача як root, а потім негайно переходите до git init, не змінюючи користувача між ними.

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

Linux, macOS:

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

де nameваше ім’я користувача та groupгрупа, до якої належить ваше ім’я користувача.

Після того, як ви додасте кілька речей ... виконайте їх і, нарешті, готові натисніть! БАНГ !! Почніть всі проблеми ... Як слід зауважити, є певні відмінності у визначенні як нових, так і існуючих проектів. Якщо хтось інший спробує додати / зробити / пересувати ті самі файли чи вміст (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 object (.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

У моєму випадку жодна з пропозицій не спрацювала. Я в Windows, і це працювало для мене:

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

Я торкнувся цього самого питання. Читаючи тут, я зрозумів, що це дозволи на файли, на які посилалося повідомлення. Для мене виправлення полягало в:

/etc/inetd.d/git-gpv

Це було запуском 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)

Вам потрібні достатні дозволи на запис у каталог, на який ви натискаєте.

У моєму випадку: сервер Windows 2008

клацніть правою кнопкою миші на каталог git repo або батьківський каталог.

Властивості> вкладка Спільний доступ> Розширений спільний доступ> Дозволи> переконайтеся, що користувач має відповідні права доступу.

Можливо, ви випадково вклали сховища git

Є ймовірність, що ви додали ще один локальний сховище з тим самим псевдонімом. Наприклад, у вас є дві локальні папки, згадані originтак, коли ви намагаєтесь натиснути, віддалене сховище не прийме ваших облікових даних.

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

Можливо, ви можете залишити 1 місцевий сховище за своїм смаком, originа інші перейменувати їх, наприклад, з originна anotherorigin. Пам'ятайте, що це лише псевдоніми, і все, що вам потрібно зробити, це запам'ятати нові псевдоніми та їх відповідні віддалені відділення.

Працює для мене

sudo chmod -R g+rwX .

Це я отримав, коли брав участь у проекті Rstudio. Я зрозумів, що забув зробити:

sudo rstudio

при запуску програми. Насправді, оскільки у мене є ще одна помилка, мені потрібно зробити:

sudo rstudio --no-sandbox

Використовуйте судо для фіксації -м

• git add -A
• sudo git commit -m "Використовувати sudo для фіксувати -m"
• git push origin branch_name

Я отримував цю проблему з віддаленим сховищем на акції Samba; Я успішно витягнув з цього пульта, але не вдався при натисканні на нього.

Причиною помилки стали неправильні облікові дані в моєму ~/.smbcredentialsфайлі.