Помилка при натисканні на GitHub - недостатній дозвіл на додавання об’єкта до бази даних сховища

Я повертаюсь до незвичної помилки під час спроби зробити "git push" до мого сховища GitHub:

Підрахунок об’єктів: 8, зроблено.
Дельта стиснення за допомогою 2 ниток.
Стиснення предметів: 100% (4/4), зроблено.
Написання об'єктів: 100% (5/5), 1,37 KiB, виконано.
Всього 5 (дельта 2), повторно використане 0 (дельта 0)
помилка: недостатній дозвіл на додавання об'єкта до бази даних сховища ./objects

фатально: не вдалося записати об’єкт
помилка: розпаковуються об'єкти, що вийшли з кодом помилки 128
помилка: розпакування не вдалося: розпакувати об’єкти ненормальний вихід
На git@github.com: bixo / bixo.git
 ! [віддалено відхилено] master -> master (n / a (помилка розпакування))
помилка: не вдалося надіслати деякі відгуки на 'git@github.com: bixo / bixo.git'

• Після чистого клону з GitHub я можу редагувати / додавати / фіксувати / висувати модифікований файл.
• Якщо я повторю це вдруге, я отримую вищевказану помилку.
• Я можу добре перейти до інших сховищ GitHub.
• Я перевірив дозволи на файли / каталоги на моїй стороні, і вони здаються нормальними.
• Я працюю git 1.6.2.3 на Mac OS X 10.5.8

Наведене вище сховище стало моїм задоволенням для попереднього запитання про переповнення стека ( SO 1904860 ), тому, можливо, репортаж GitHub зіпсувався. Єдина подібна проблема, яку я знайшов за допомогою пошуку, - це проблема розпакування, що не вдалося повідомити про github. Хто-небудь ще стикався з цією проблемою раніше, особливо коли не використовується GitHub?

Якщо ви бачите цю помилку поза github, ось такий спосіб усунення.

Отримав це з: http://mapopa.blogspot.com/2009/10/git-insufficient-permission-for-adding.html

ssh me@myserver
cd repository/.git

sudo chmod -R g+ws *
sudo chgrp -R mygroup *

git config core.sharedRepository true

Після цього демон git повинен використовувати дозволи групового файлу під час запису в .git / об’єкти.

Зазвичай ця проблема викликана неправильними дозволами користувачів та груп у вашій файловій системі Git серверів. Репозиторій git повинен належати користувачеві, а також його групі.

Приклад:

Якщо вашого користувача називають "git", його група "gitgroup", а місцезнаходження Git repo: git@mygitserverxyz.com: path / to / repo.git

тоді зробіть:

sudo chown -R git: шлях до gitgroup / до / repo.git /

Це виправило недостатню помилку дозволу для git.

sudo chmod 777 -R .git/objects

Це сталося зі мною, коли я намагався git pull. Деякий аналіз показав, що хтось займався коренем у минулому, тим самим створюючи деякі об'єкти із власністю root.git/objects .

Тому я побіг

cd <repo>
la .git/objects/

і це показало rootправо власності на деякі об'єкти (каталоги) на зразок цього:

user@host:/repo> la .git/objects/
total 540
drwxr-xr-x 135 user user 4096 Jun 16 16:29 .
drwxr-xr-x   8 user user 4096 Jun 16 16:33 ..
drwxr-xr-x   2 user user 4096 Mar  1 17:28 01
drwxr-xr-x   2 user user 4096 Mar  1 17:28 02
drwxr-xr-x   2 user user 4096 Jun 16 16:27 03
drwxr-xr-x   2 user user 4096 Mar  3 13:22 04
drwxr-xr-x   2 root root 4096 Jun 16 16:29 05
drwxr-xr-x   2 user user 4096 Jun 16 16:28 07
drwxr-xr-x   2 root root 4096 Jun 16 16:29 08

Потім я побіг

sudo chown -R user:user .git/objects/

і це спрацювало!

Звичайно, я замінював користувача справжнім користувачем.

Ніщо з перерахованого вище не працювало для мене. Через пару годин я знайшов причину проблеми: я використав URL-адресу типу repo

ssh://git@example.com/~git/repo.git

На жаль, я зберігав сеанс шпаклівки з ім'ям, example.comяке було налаштовано для входу як користувач myOtherUser.

Отже, хоча я думав, що git підключається до хоста example.comз користувачем 'git', Git / TortoiseGit підключився до сесії шпаклівки, example.comяка використовує Користувач myOtherUser. Це призводить до абсолютно однакової ..insufficient permission..помилки ( оскільки обидва користувачі знаходяться в різних групах).

Рішення: Перейменуйте сеанс шпаклівки example.comнаmyOtherUse@example.com

chmod має бути chown, тому правильний рядок:

sudo chown -R gituser:gituser objects

Як не дивно, я мав цю проблему на одному клоні репо, який у мене був, але не в іншому. Окрім повторного клонування репо (що колега зробив, щоб успішно обійти цю проблему), мені вдалося виконати "перезавантаження" до виконання зобов'язань перед початком невдач. Потім я знову вчинив зміни, і мені вдалося успішно просунутись після цього. Тож, незважаючи на всі вказівки, на сервері виникла проблема, в цьому випадку це, мабуть, свідчить про деяку дивацтво у місцевому репо.

Я отримував цю помилку, оскільки кожен раз, коли користувач натискав якийсь вміст, група файлів змінювалася на користувача. І тоді, якщо якийсь інший користувач намагався просунутись у сховище, це спричинило помилку дозволу, і натискання було відхилено. Тому потрібно попросити свого sysadmin змінити параметри сховища, щоб група будь-якого файлу в сховищі не змінювалася ні на який натискання будь-яким користувачем.

Щоб уникнути подібної проблеми, переконайтеся, що при ініціалізації вашого сховища git використовуйте команду "git init --shared = group".

Якщо ви все-таки отримаєте цю помилку пізніше після встановлення дозволів, можливо, вам знадобиться змінити маску створення. Ми виявили, що наші нові коміти (папки під об’єктами) все ще створюються без дозволу на групове письмове запитання, отже, лише той, хто їх вчинив, може просунутись у сховище.

Ми виправили це, встановивши umask користувачів SSH на 002 з відповідною групою, спільною для всіх користувачів.

напр

umask 002

де середній 0 дозволяє груповому записувати за замовчуванням.

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

Спробуйте зробити наступне:

Перейдіть на Ваш сервер

    cd rep.git
    chmod -R g+ws *
    chgrp -R git *
    git config core.sharedRepository true

Потім перейдіть до вашої робочої копії (локальне сховище) і запакуйте її git repack master

Мені прекрасно працює.

Ви можете скористатися цим

sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"

sudo su root

chown -R user:group dir

Режисер - це ваше git repo.

Потім зробіть:

git pull origin master

Ви побачите зміни щодо комісій інших.

 user@M063:/var/www/html/app/.git/objects$ sudo chmod 777 -R .git/objects
 user@M063:/var/www/html/app/.git/objects$ sudo chown -R user:user .git/objects/

Гаразд - виявляється, що проблема з дозволом на GitHub сталася під час розщеплення emi / bixo до bixo / bixo. Як тільки Tekkub виправив це, він знову почав працювати.

Оскільки помилка стосується дозволів на папку об'єктів, я зробив заклинання безпосередньо в папці об'єктів, і це працювало на мене.

Це працює:

sudo chmod -R gituser.gituser objects

Я думаю, що багато хто з мене опиняється на таких форумах, коли проблема з git, як описано вище, виникає. Однак існує так багато причин, які можуть призвести до проблеми, що я просто хочу поділитися тим, що спричинило мої неприємності для інших, як я вже дізнався згори.

У мене є репост про Linux NAS від sitecom (Ніколи не купуйте NAS від Sitecom, благання). У мене тут є репо, яке клоновано на багатьох комп’ютерах, але мені раптом відмовили в натисканні. Нещодавно я встановив плагін, щоб мій NAS міг стояти як сервер стискання.

Цей сервер сканує засоби масової інформації для спільного доступу. Що я не знав, це те, що можливо через помилку, сервер змінює налаштування користувача та групи, щоб видавити: user для всіх файлів, які він шукає. І це ВСІ файли. Таким чином, змінити права, які мені довелося домагатися.

Сервер відсутній і належні налаштування прав відновлюються, і все працює бездоганно.

я використав

chmod -R g+ws *
chown -R <myuser>:<mygroup> *

Там, де мійсер та мої групи поза курсом повинні бути замінені належними налаштуваннями для вашої системи. спробуйте git: git або gituser: gituser або щось інше, що вам може сподобатися.,

Перевірте сховище: $ git remote -v

origin  ssh://git@example.com:2283/srv/git/repo.git (fetch)
origin  ssh://git@example.com:2283/srv/git/repo.git (push)

Зауважте, що тут є підрядка 'git @', вона вказує git аутентифікувати як ім'я користувача git на віддаленому сервері. Якщо ви опустите цей рядок, git перевірятиме автентифікацію під іншим іменем користувача, отже, ця помилка стане.

У моєму випадку між моєю машиною та віртуальним сервером git не було уніфікованої аутентифікації (наприклад, у домені + AD-подібній службі). Тому користувачі git та група є локальними для віртуального сервера. У моєму випадку мого віддаленого користувача (якого я використовую для входу на віддалений сервер) просто не додавали до віддаленої групи git.

ssh root@<remote_git_server>
usermod -G <remote_git_group> <your_remote_user>

Після цього перевірте дозволи, як це описано у публікаціях вище ...

Ви спробували sudo git push -u походження - всі ? Іноді це єдине, що потрібно, щоб уникнути цієї проблеми. Він запитує вас про пароль адміністратора - той, на який ви можете зробити авторизацію на вашій машині - і це те, що вам потрібно натиснути - або здійснити, якщо це так.