git: не могу отправить (ошибка распаковщика), связанные с проблемами разрешения

Question

git: не могу отправить (ошибка распаковщика), связанные с проблемами разрешения

У меня есть эта проблема, когда я пытаюсь нажать в git:

error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://<repo url>/<repo dir>
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://<repo url>/<repo dir>'

У меня было это раньше время от времени, и нам всегда приходилось решать эту проблему, когда каждый пользователь переходит в репозиторий и устанавливает групповые разрешения для всех файлов в нем с помощью

chmod -R g+w *

Это никогда не было удовлетворительным решением, и теперь оно укусило нас в задницу, потому что один из парней отсутствует, и никто не знает пароль пользователя его репо. Итак, я пытаюсь решить это правильно.

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

1) убедитесь, что группа, с которой разделены папки репо, является основной группой каждого пользователя (я полагаю, что это уже так: у каждого пользователя есть только одна группа, так что это должна быть их основная группа, верно?)

2) настройка git repo core.sharedRepository, как подробно описано здесь: Git: не могу нажать с одного компьютера, я изменил это, но это не имело никакого значения. Нужно ли перезагружать конфигурацию или что-то еще, чтобы фактически повлиять на изменение?

Вот как выглядит мой репозиторий:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedRepository = all
[receive]
        denyNonFastForwards = True

Благодарен за любые советы или предложения! Максимум

71

linux git

Источник

user138557 26 окт '10 в 16:25

15 ответов

Другие вопросы по тегам linux git

user1259614 12 авг '13 в 21:26 2013-08-12 21:26 · Answer 1 · 2013-08-12 21:26

У меня была эта ошибка в течение двух недель, и большинство решений указали в качестве ответа "chmod -R", к сожалению для меня все мои репозитории git (локальные / удаленные / общие - с командой) были в ОС Windows, и хотя chmod -Rv показал, что все файлы были изменены на "rwxrwxrwx", последующий "ls -l" по-прежнему отображал все файлы как "rwxr-xr-x", и ошибка повторилась. В конце концов я увидел это решение от Арьеян де Врум. Это сработало, и мы все смогли тянуть и толкать снова.

На локальных (локальных, которые испытывают затруднения при отправке) и удаленных репозиториях выполните следующие команды:

$ git fsck
$ git prune
$ git repack
$ git fsck

Кстати, я попытался использовать собственные права доступа к файлам Windows / ACL и даже обратился к поднятию проблемного пользователя до администратора, но, похоже, ничего из этого не помогло. Не уверен, что среда важна, но она может помочь кому-то с подобной настройкой - проблемный член команды и удаленный (Windows Server 2008 R2 Standard) мой локальный (Windows 7 VM).

user511971 24 янв '11 в 23:50 2011-01-24 23:50 · Answer 2 · 2011-01-24 23:50

Более простой способ сделать это - добавить скрипт post-receive, который запускает команду chmod после каждого нажатия на репозиторий "hub" на сервере. Добавьте следующую строку в hooks/post-receive внутри вашей папки git на сервере:

chmod -Rf u+w /path/to/git/repo/objects

30

Источник

user511971 24 янв '11 в 23:50

user1105203 18 сен '12 в 03:14 2012-09-18 03:14 · Answer 3 · 2012-09-18 03:14

Это ошибка разрешения. Для меня наиболее подходящим и безопасным способом было добавление пользователей в дополнительную группу репо. принадлежит (или наоборот):

groupadd git
chgrp -R git .git
chgrp -R git ./
usermod -G -a git $(whoami)

9

Источник

user1105203 18 сен '12 в 03:14

user805284 04 сен '12 в 23:07 2012-09-04 23:07 · Answer 4 · 2012-09-04 23:07

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

http://blog.shamess.info/2011/05/06/remote-rejected-na-unpacker-error/

Это просто работает.

user980423 11 май '16 в 12:47 2016-05-11 12:47 · Answer 5 · 2016-05-11 12:47

Для меня эта ошибка произошла, когда на моем пульте не было места.

Мне просто нужно прочитать остальную часть сообщения об ошибке:

error: file write error (No space left on device)
fatal: unable to write sha1 file
error: unpack failed: unpack-objects abnormal exit

5

Источник

user980423 11 май '16 в 12:47

user4769395 27 июн '18 в 02:02 2018-06-27 02:02 · Answer 6 · 2018-06-27 02:02

Что касается ошибки разрешения с использованием репозитория git в экземпляре AWS, я успешно решил ее, создав группу и рекурсивно назначив ее в папку репозитория (-R), и предоставив право на запись этой группе, а затем назначив пользователя экземпляра aws по умолчанию. (ec2-user или ubuntu) в эту группу.

1. Создайте имя группы share_group или что-то еще

     sudo groupadd share_group

2. измените папку репозитория из группы "root" на "share_group"

     sudo chgrp -R share_group /path/to/your/repository

3. добавить полномочия записи в share_group

     sudo chmod -R g+w /path/to/your/repository

4. Последний шаг - назначить текущего пользователя - пользователя по умолчанию при входе в систему (по умолчанию ec2 - "ec2-пользователь", пользователь экземпляра ubuntu - "ubuntu" в ubuntu на aws) для share_group. Я использую Ubuntu Insance на AWS, поэтому мой пользователь по умолчанию Ubuntu.

     sudo usermod -a -G share_group ubuntu

Кстати, чтобы увидеть владельца папки или файла, просто наберите:

    ls -l  /path/to/your/repository

'

Выход:

    drwxr-x--x  2 root shared_group

(объяснение см. по адресу: https://wiki.archlinux.org/index.php/File_permissions_and_attributes).

После шага 3 вы увидите

    drwx--x--x  2 root root

изменился на

    drwxr-x--x  2 root share_group

В этом случае я не назначил пользователя 'ubuntu' в корневую группу для обеспечения безопасности. Вы можете просто попытаться назначить пользователя по умолчанию пользователем root согласно шагу 4 (просто пропустите первые 3 шага

По-другому, пробовал решение по:

    chmod -Rf u+w /path/to/git/repo/objects

У меня это не сработало, я думаю, что это должно быть причиной того, что моя папка репозитория принадлежит пользователю root, а не пользователю Ubuntu, и в 'git' по умолчанию используется пользователь по умолчанию (пользователь ec2 или пользователь Ubuntu. Вы можете попробовать изменить пользователя и проверить его.

Наконец, приведенный ниже код определенно работает для меня, но 777 не годится для безопасности

    sudo chmod -R 777 /path/to/your/repo

user474283 26 окт '10 в 16:31 2010-10-26 16:31 · Answer 7 · 2010-10-26 16:31

Я использую Gitosis для управления такого рода вещами. У Gitosis есть один пользователь (обычно называемый "git"), которому принадлежат все репозитории, и он использует управление доступом на основе открытого ключа к каждому репо. Это может не подходить к вашей настройке, но, вероятно, стоит проверить (не каламбур).

user794212 14 ноя '13 в 00:26 2013-11-14 00:26 · Answer 8 · 2013-11-14 00:26

Я получаю похожую ошибку и, пожалуйста, смотрите ниже, как я ее исправил

Моя структура каталогов: /opt/git/project.git, а пользователь git - это git

$ cd /opt/git/project.git
$ sudo chown -R git:git .

chown с параметром -R рекурсивно меняет владельца и группу и (так как я набрал git:git в приведенной выше команде) текущего каталога. chown -R необходим, так как git изменяет многие файлы в вашем каталоге git, когда вы отправляете в репозиторий.

user187273 24 янв '13 в 12:09 2013-01-24 12:09 · Answer 9 · 2013-01-24 12:09

Эта проблема также может возникнуть после обновлений Ubuntu, которые требуют перезагрузки.

Если файл /var/run/reboot-required существует, сделать или запланировать перезагрузку.

2

Источник

user187273 24 янв '13 в 12:09

user192819 20 апр '11 в 19:57 2011-04-20 19:57 · Answer 10 · 2011-04-20 19:57

У меня тоже были проблемы с этим, думая, что мой удаленный администратор gitolite был поврежден или что-то не так.

Моя установка - ноутбук Mac OS X (10.6.6) с удаленным сервером Ubuntu 10 с gitolite.

Оказалось, что проблема была с моей локальной проверкой gitolite-admin.

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

Я понял это, снова проверив это как gitolite-admin2, внеся изменения и нажав.

Вуаля! Это сработало!

user1198291 22 дек '14 в 10:02 2014-12-22 10:02 · Answer 11 · 2014-12-22 10:02

Что бы это ни стоило, у меня была та же проблема с моим собственным VPS, и это было вызвано моим низким объемом жесткого диска на VPS. Подтверждено df -h команда и после того, как я очистил жесткий диск моего VPS; проблема исчезла

Приветствия.

1

Источник

user1198291 22 дек '14 в 10:02

user4864925 24 дек '22 в 03:45 2022-12-24 03:45 · Answer 12 · 2022-12-24 03:45

У меня была похожая проблема, как это раньше:

       ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'https://mywebsite.com/my-git-directory.git'

В моем случае я проверил неправильное владение каталогом с помощьюls -l. Я меняю владельца каталога наwww-dataрешить проблему следующим образом:

      sudo chown -R www-data:www-data my-git-directory.git/

Но в этом случае я не использую метод SSH, я использую метод HTTP.

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

user2662728 04 апр '22 в 19:19 2022-04-04 19:19 · Answer 13 · 2022-04-04 19:19

Ошибка конфигурации git также может привести к этой ошибке. Я даю своим ученикам и пример такой конфигурации:

      git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Один из моих студентов получил ошибку распаковщика. Другие студенты были в порядке, но я все же дважды проверил разрешения сервера git и убедился, что студент находится в правильной группе.

Наконец, я попросил студента сделать журнал git и увидел, что у него есть John Doe для его конфигурации, но его ветка была его собственным именем.

Правильная настройка его конфигурации устранила ошибку.

user1078332 10 июн '14 в 18:13 2014-06-10 18:13 · Answer 14 · 2014-06-10 18:13

Там, где я работаю, мы использовали этот метод во всех наших репозиториях в течение нескольких лет без каких-либо проблем (кроме случаев, когда мы создаем новый репозиторий и забываем настроить его таким образом):

Установите "sharedRepository = true" в разделе "[core]" файла конфигурации.
Измените идентификатор группы репозитория на группу, доступную для всех пользователей, которым разрешено передавать в нее данные:
```
chgrp -R shared_group /git/our_repos
chmod -R g+w /git/our_repos
```
Установите бит setgid для всех каталогов в хранилище, чтобы новые файлы / каталоги оставались в той же группе:
```
find /git/our_repos -type d -exec chmod g+s {} +
```
Добавьте эту строку в ловушку предварительного получения в хранилище, чтобы новые разрешения доступа к файлам разрешали групповое чтение / запись:
```
umask 007
```

user1085736 04 янв '16 в 16:38 2016-01-04 16:38 · Answer 15 · 2016-01-04 16:38

Для меня это проблема с разрешениями:

На сервере git выполните эту команду в каталоге репо

sudo chmod -R 777 theDirectory/

0

Источник

user1085736 04 янв '16 в 16:38