Błąd podczas wypychania do GitHub - niewystarczające uprawnienia do dodania obiektu do bazy danych repozytorium

Otrzymuję nietypowy błąd podczas próby wykonania polecenia „git push” do mojego repozytorium GitHub:

Liczenie obiektów: 8, gotowe.
Kompresja delta za pomocą 2 wątków.
Kompresja obiektów: 100% (4/4), gotowe.
Pisanie obiektów: 100% (5/5), 1,37 KiB, gotowe.
Łącznie 5 (delta 2), ponownie wykorzystane 0 (delta 0)
błąd: niewystarczające uprawnienia do dodania obiektu do bazy danych repozytorium ./objects

fatal: nie udało się zapisać obiektu
błąd: rozpakowywanie obiektów zakończyło się z kodem błędu 128
błąd: rozpakowanie nie powiodło się: unpack-objects nieprawidłowe wyjście
Do [email protected]: bixo / bixo.git
 ! [zdalne odrzucenie] wzorzec -> nadrzędny (nie dotyczy (błąd rozpakowywania))
błąd: nie udało się przesłać niektórych odnośników do „[email protected]: bixo / bixo.git”

• Po czystym klonie z GitHub mogę edytować / dodawać / zatwierdzać / przesyłać zmodyfikowany plik.
• Jeśli powtórzę to po raz drugi, otrzymam powyższy błąd.
• Mogę dobrze przesłać do innych repozytoriów GitHub.
• Sprawdziłem uprawnienia do plików / katalogów po mojej stronie i wydają się OK.
• Używam git 1.6.2.3 na Mac OS X 10.5.8

Powyższe repozytorium było źródłem mojej radości z poprzedniego pytania o przepełnienie stosu ( SO 1904860 ), więc może repozytorium GitHub zostało uszkodzone. Jedynym podobnym problemem, jaki znalazłem podczas wyszukiwania, był problem z rozpakowaniem zgłoszony na github. Czy ktoś inny napotkał ten problem wcześniej, zwłaszcza gdy nie korzysta z GitHub?

Jeśli widzisz ten błąd poza githubem, oto rozwiązanie.

Mam to z: 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

Następnie demon git powinien używać praw dostępu do pliku grupy podczas zapisywania do .git / objects.

Zwykle ten problem jest spowodowany nieprawidłowymi uprawnieniami użytkowników i grup w systemie plików serwerów Git. Repozytorium git musi być własnością użytkownika, a także jego grupy.

Przykład:

Jeśli Twój użytkownik nazywa się „git”, jego grupa „gitgroup”, a lokalizacja repozytorium Git to: [email protected]: ścieżka / do / repo.git

następnie wykonaj:

sudo chown -R git: gitgroup ścieżka / do / repo.git /

To naprawiło błąd git niewystarczających uprawnień.

sudo chmod 777 -R .git/objects

Przydarzyło mi się to, kiedy próbowałem git pull. Niektóre analizy wykazały, że ktoś w przeszłości korzystał z uprawnień roota, tworząc w ten sposób obiekty z prawami własności roota .git/objects.

Więc uciekłem

cd <repo>
la .git/objects/

i to pokazało rootwłasność niektórych obiektów (katalogów), takich jak ten:

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

Potem uciekłem

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

i zadziałało!

Oczywiście zastępowałem użytkownika moim rzeczywistym użytkownikiem.

Nic z powyższego nie działało dla mnie. Kilka godzin później znalazłem przyczynę problemu: użyłem repozytorium URL typu

ssh://[email protected]/~git/repo.git

Niestety zapisałem sesję szpachlówki o nazwie example.comskonfigurowanej do logowania się jako użytkownik myOtherUser.

Tak więc, podczas gdy myślałem, że git łączy się z hostem example.comza pomocą „git” użytkownika, Git / TortoiseGit połączył się z sesją putty, example.comktóra używa użytkownika myOtherUser. Prowadzi to do dokładnie tego samego ..insufficient permission..błędu (ponieważ obaj użytkownicy są w różnych grupach).

Rozwiązanie: Zmień nazwę sesji szpachlowania example.comna[email protected]

chmod powinno być chown, więc prawidłowa linia to:

sudo chown -R gituser:gituser objects

Co dziwne, miałem ten problem z jednym klonem repozytorium, które miałem, ale nie miałem innego. Oprócz ponownego sklonowania repozytorium (co zrobił współpracownik, aby z powodzeniem obejść ten problem), udało mi się wykonać „reset git” do zatwierdzenia, które miałem przed wystąpieniem awarii. Następnie ponownie zatwierdziłem zmiany i po tym mogłem pomyślnie przejść. Więc pomimo wszystkich wskazówek, na serwerze wystąpił problem, w tym przypadku najwyraźniej wskazywał on na jakąś dziwność w lokalnym repozytorium.

Otrzymałem ten błąd, ponieważ za każdym razem, gdy użytkownik wypycha jakąś zawartość, grupa pliku zmieniała się na użytkownika. A potem, jeśli inny użytkownik próbował wepchnąć do repozytorium, spowodował błąd uprawnień i push został odrzucony. Dlatego należy poprosić administratora systemu, aby zmienił ustawienia repozytorium, aby grupa żadnego pliku w repozytorium nie była zmieniana dla żadnego wypychania przez dowolnego użytkownika.

Aby uniknąć takiego problemu, upewnij się, że podczas inicjalizacji repozytorium git użyj polecenia „git init --shared = group”.

Jeśli po ustawieniu uprawnień nadal pojawia się ten błąd , może być konieczne zmodyfikowanie maski tworzenia. Okazało się, że nasze nowe zatwierdzenia (foldery pod obiektami) są nadal tworzone bez uprawnień do zapisu grupowego, dlatego tylko osoba, która je popełniła, mogła wrzucić do repozytorium.

Naprawiliśmy to, ustawiając umask użytkowników SSH na 002 z odpowiednią grupą współdzieloną przez wszystkich użytkowników.

na przykład

umask 002

gdzie środkowe 0 domyślnie zezwala na zapis grupowy.

Po dodaniu kilku rzeczy ... zatwierdź je, a po wszystkim odepchnij! HUK!! Rozpocznij wszystkie problemy ... Jak powinieneś zauważyć, istnieją pewne różnice w sposobie definiowania zarówno nowych, jak i istniejących projektów. Jeśli jakaś inna osoba spróbuje dodać / zatwierdzić / przesłać te same pliki lub zawartość (git zachowuje oba te same obiekty), napotkamy następujący błąd:

$ 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

Aby rozwiązać ten problem, musisz mieć coś na uwadze system uprawnień systemu operacyjnego, ponieważ w tym przypadku jesteś przez niego ograniczony. Aby lepiej zrozumieć problem, przejdź dalej i sprawdź folder swojego obiektu git (.git / objects). Prawdopodobnie zobaczysz coś takiego:

<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

* Pamiętaj, że uprawnienia do tych plików zostały przyznane tylko Twoim użytkownikom, nikt nigdy nie będzie mógł ich zmienić ... *

Level       u   g   o
Permission rwx r-x ---
Binary     111 101 000
Octal       7   5   0

ROZWIĄZYWANIE PROBLEMU

Jeśli masz uprawnienia superużytkownika, możesz przejść dalej i zmienić wszystkie uprawnienia samodzielnie, korzystając z kroku drugiego, w każdym innym przypadku będziesz musiał zapytać wszystkich użytkowników z obiektami utworzonymi z ich użytkownikami, użyj następującego polecenia, aby wiedzieć, kim oni są :

$ ls -la | awk '{print $3}' | sort -u 
<your user_name>
<his user_name>

Teraz Ty i wszyscy użytkownicy będący właścicielami pliku musicie zmienić uprawnienia tych plików, wykonując:

$ chmod -R 774 .

Następnie będziesz musiał dodać nową właściwość, która jest równoważna z --shared = group wykonaną dla nowego repozytorium, zgodnie z dokumentacją, dzięki temu repozytorium będzie można zapisywać w grupie, zrób to wykonując:

$ git config core.sharedRepository group

https://coderwall.com/p/8b3ksg

Spróbuj wykonać następujące czynności:

Przejdź do swojego serwera

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

Następnie przejdź do kopii roboczej (repozytorium lokalne) i zapakuj ją ponownie git repack master

U mnie działa idealnie.

możesz tego użyć

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

sudo su root

chown -R user:group dir

Katalog jest twoim repozytorium git.

Następnie wykonaj:

git pull origin master

Zobaczysz zmiany w zatwierdzeniach innych osób.

 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/

OK - okazuje się, że był to problem z uprawnieniami na GitHubie, który wystąpił podczas rozwidlenia emi / bixo do bixo / bixo. Gdy Tekkub to naprawił, zaczął ponownie działać.

Ponieważ błąd dotyczy uprawnień do folderu obiektów, zrobiłem przegląd bezpośrednio w folderze obiektów i zadziałało.

To działa:

sudo chmod -R gituser.gituser objects

Myślę, że wielu takich jak ja trafia na takie fora, gdy pojawia się problem z gitem, jak opisano powyżej. Jednak jest tak wiele przyczyn, które mogą prowadzić do problemu, że chcę tylko podzielić się tym, co spowodowało moje problemy, aby inni mogli się uczyć, tak jak nauczyłem się już z góry.

Mam swoje repozytoria na serwerze NAS z systemem Linux od firmy Sitecom (nigdy nie kupuj NAS od Sitecom, proszę). Mam tutaj repozytorium, które jest sklonowane na wielu komputerach, ale któremu nagle odmówiono. Niedawno zainstalowałem wtyczkę, aby mój NAS mógł pełnić rolę serwera squeezebox.

Ten serwer wyszukuje multimedia do udostępnienia. Nie wiedziałem, że jest to możliwe z powodu błędu, że serwer zmienia ustawienia użytkownika i grupy na squeeze: user dla wszystkich plików, które przegląda. I to są WSZYSTKIE pliki. Zmieniając w ten sposób prawa, które musiałem forsować.

Serwer zniknął, przywracane są odpowiednie ustawienia praw i wszystko działa idealnie.

użyłem

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

Gdzie myuser i mygroup poza kursem należy zastąpić odpowiednimi ustawieniami dla twojego systemu. spróbuj git: git lub gituser: gituser lub coś innego, co może ci się spodobać.,

Sprawdź repozytorium: $ git remote -v

origin  ssh://[email protected]:2283/srv/git/repo.git (fetch)
origin  ssh://[email protected]:2283/srv/git/repo.git (push)

Zauważ, że istnieje tutaj podciąg „git @”, który instruuje git, aby uwierzytelnił się jako nazwa użytkownika „git” na zdalnym serwerze. Jeśli pominiesz tę linię, git uwierzytelni się pod inną nazwą użytkownika, stąd ten błąd wystąpi.

W moim przypadku nie było ujednoliconego uwierzytelniania (np. W ramach domeny + usługi typu AD) pomiędzy moją maszyną a wirtualnym serwerem git. Dlatego użytkownicy i grupa git są lokalni dla serwera wirtualnego. W moim przypadku mój zdalny użytkownik (którego używam do logowania się do zdalnego serwera) po prostu nie został dodany do zdalnej grupy git.

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

Następnie sprawdź uprawnienia, jak opisano w powyższych postach ...

Czy wypróbowałeś sudo git push -u origin --all ? Czasami jest to jedyna rzecz, której potrzebujesz, aby uniknąć tego problemu. Pyta cię o hasło systemowe administratora - to, którego możesz zalogować się do swojego komputera - i to właśnie musisz wypchnąć - lub zatwierdzić, jeśli tak jest.