Ошибка отправки в GitHub - недостаточно прав для добавления объекта в базу данных репозитория.
Я получаю необычную ошибку при попытке сделать "git push" в мой репозиторий GitHub:
Подсчет объектов: 8, сделано. Дельта-сжатие с использованием 2 потоков. Сжатие объектов: 100% (4/4), сделано. Написание объектов: 100% (5/5), 1,37 КиБ, сделано. Всего 5 (дельта 2), повторно 0 (дельта 0) ошибка: недостаточно прав для добавления объекта в базу данных хранилища./objects фатальный: не удалось записать объект ошибка: распаковка объектов завершена с кодом ошибки 128 ошибка: не удалось распаковать: аварийный выход из распакованного объекта Для git@github.com:bixo/bixo.git! [удаленный отклоненный] мастер -> мастер (н / д (ошибка распаковщика)) ошибка: не удалось отправить некоторые ссылки на git@github.com: bixo / bixo.git
- После чистого клона из GitHub я могу редактировать / добавлять / фиксировать / отправлять измененный файл.
- Если я тогда повторю это во второй раз, я получу вышеуказанную ошибку.
- Я могу просто нажать на другие репозитории GitHub.
- Я проверил права доступа к файлам / каталогам на моей стороне, и они, кажется, в порядке.
- Я использую git 1.6.2.3 на Mac OS X 10.5.8
Приведенный выше репозиторий был источником моего удовольствия от предыдущего вопроса переполнения стека ( SO 1904860), так что, возможно, репозиторий GitHub поврежден. Единственная похожая проблема, которую я обнаружил при поиске, была проблема с распаковкой, о которой сообщалось на github. Кто-нибудь еще сталкивался с этой проблемой прежде, особенно когда не используется GitHub?
21 ответ
Когда вы видите эту ошибку за пределами 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/objects.
Обычно эта проблема вызвана неправильными правами пользователей и групп в файловой системе Git-серверов. Git-репозиторий должен принадлежать как пользователю, так и его группе.
Пример:
Если ваш пользователь называется "git", его группа "gitgroup" и местоположение репозитория Git: git@mygitserverxyz.com: путь / к / repo.git
затем сделайте:
sudo chown -R git: путь к gitgroup / to / repo.git /
Это исправило ошибку недостаточного разрешения для меня.
Это случилось со мной, когда я пытался git pull, Некоторый анализ показал, что кто-то связывался с root в прошлом, создавая, таким образом, некоторые объекты с правами 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 репо типа
ssh://git@example.com/~git/repo.git
К сожалению, я сохранил замазку с именем example.com который был настроен для входа в систему как пользователь myOtherUser,
Итак, пока я думал, что git подключается к хосту example.com с пользователем 'git', Git/TortoiseGit подключился к сеансу putty example.com который использует пользователя myOtherUser, Это приводит к точно так же ..insufficient permission.. ошибка (потому что оба пользователя находятся в разных группах).
Решение: переименуйте сеанс замазки example.com в myOtherUse@example.com
chmod должен быть chown, поэтому правильная строка:
sudo chown -R gituser:gituser objects
Как ни странно, у меня была эта проблема с одним клоном репо, но не с другим. Помимо повторного клонирования репозитория (что коллега сделал, чтобы успешно обойти эту проблему), мне удалось выполнить "git reset" для коммита, который был у меня до начала сбоев. Затем я повторно зафиксировал изменения, и после этого мне удалось успешно продвинуться. Таким образом, несмотря на все признаки, на сервере возникла проблема, в данном случае это явно указывало на некоторую странность в локальном репо.
Я получал эту ошибку, потому что каждый раз, когда пользователь нажимал какой-то контент, группа файла изменялась на пользователя. И затем, если какой-то другой пользователь попытался вставить в хранилище, это вызвало ошибку разрешения, и отправка была отклонена. Поэтому нужно попросить вашего системного администратора изменить настройки репозитория, чтобы группа любого файла в репозитории не изменялась ни для какого пользователя.
Чтобы избежать такой проблемы, убедитесь, что при инициализации вашего git-репозитория используйте команду "git init --shared=group".
Если вы по-прежнему получаете эту ошибку позже, после установки разрешений, вам может потребоваться изменить маску создания. Мы обнаружили, что наши новые коммиты (папки под объектами) по-прежнему создавались без разрешения на запись в группу, поэтому только тот, кто их зафиксировал, мог войти в репозиторий.
Мы исправили это, установив umask пользователей SSH на 002 с соответствующей группой, доступной всем пользователям.
например
umask 002
где средний 0 разрешает групповую запись по умолчанию.
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/
sudo su root
chown -R user:group dir
Dir - это твое мерзавец.
Затем сделайте:
git pull origin master
Вы увидите изменения в коммитах других.
Вы пробовали sudo git push -u origin --all? Иногда это единственное, что вам нужно, чтобы избежать этой проблемы. Он запрашивает у вас системный пароль администратора - тот, который вы можете использовать для входа в систему на своем компьютере, - и это то, что вам нужно нажать - или зафиксировать, если это так.
Попробуйте сделать следующее:
Перейти на ваш сервер
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"
После того, как вы добавите некоторые вещи... зафиксируйте их и после того, как закончите, нажмите на них 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
Проверьте хранилище: $ 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 будет аутентифицироваться под другим именем пользователя, следовательно, эта ошибка произойдет.
В моем случае не было единой аутентификации (например, в домене + служба, подобная AD) между моей машиной и виртуальным сервером git. Поэтому пользователи и группы git являются локальными для виртуального сервера. В моем случае мой удаленный пользователь (который я использую для входа на удаленный сервер) просто не был добавлен в удаленную группу git.
ssh root@<remote_git_server>
usermod -G <remote_git_group> <your_remote_user>
После этого проверьте права доступа, как описано в постах выше...
ОК - оказывается, это была проблема с разрешениями на GitHub, которая произошла во время разветвления emi/bixo в bixo/bixo. Как только Tekkub исправил это, он снова начал работать.
Так как ошибка связана с разрешениями для папки объектов, я сделал чок непосредственно в папке объектов, и это сработало для меня.
Я думаю, что многие, как я, попадают на подобные форумы, когда возникает проблема с git, как описано выше. Тем не менее, существует так много причин, которые могут привести к проблеме, и я просто хочу поделиться тем, что вызвало мои проблемы для других, чтобы узнать, как я уже учился сверху.
У меня есть репозитории на сетевом хранилище Linux от sitecom (никогда не покупайте NAS у Sitecom, pleeaaase). У меня есть репозиторий, который клонирован на многих компьютерах, но мне неожиданно было отказано в этом. Недавно я установил плагин, чтобы мой NAS мог работать как сервер squeezebox.
Этот сервер сканирует медиа для обмена. Чего я не знал, так это того, что, возможно, из-за ошибки сервер изменяет настройку пользователя и группы на squeeze: user для всех файлов, в которые он смотрит. И это ВСЕ файлы. Таким образом меняя права я должен был отодвинуть.
Сервер пропал и восстановлены правильные настройки прав, и все работает отлично.
я использовал
chmod -R g+ws *
chown -R <myuser>:<mygroup> *
Где myuser и mygroup вне курса должны быть заменены надлежащими настройками для вашей системы. попробуйте git: git или gituser: gituser или что-то еще, что вам может понравиться.,