Błąd Git Push: niewystarczające uprawnienia do dodania obiektu do bazy danych repozytorium

Kiedy próbuję przekazać na udostępnionego zdalnego git, pojawia się następujący błąd: insufficient permission for adding an object to repository database

Potem przeczytałem o poprawce tutaj: Poprawka Działało to przy następnym wypychaniu, ponieważ wszystkie pliki należały do ​​właściwej grupy, ale następnym razem, gdy ktoś podniósł zmianę, utworzył nowy element w folderze obiektów, który miał ich domyślną grupę jako grupa. Jedyne, co mogę wymyślić, to zmienić całą domyślną grupę programisty dla przedmiotów, które rejestrują, ale to wydaje się być włamaniem. Jakieś pomysły? Dzięki.

Uprawnienia do naprawy

Po zidentyfikowaniu i naprawieniu podstawowej przyczyny (patrz poniżej), będziesz chciał naprawić uprawnienia:

cd /path/to/repo.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
find . -type d -exec chmod g+s '{}' +

Uwaga: jeśli chcesz, aby wszyscy mogli modyfikować repozytorium, nie potrzebujesz chgrpi będziesz chciał zmienić chmod nasudo chmod -R a+rwX .

Jeśli nie naprawisz przyczyny, błąd będzie się powtarzał i będziesz musiał ponownie uruchamiać powyższe polecenia w kółko.

Przyczyny leżące u podstaw

Błąd może być spowodowany jedną z następujących przyczyn:

• Repozytorium nie jest skonfigurowane jako repozytorium współdzielone (patrz core.sharedRepositoryw git help config). Jeżeli wynik:

  git config core.sharedRepository
  

  nie jest grouplub truelub 1lub niektóre maski, spróbuj uruchomić:

  git config core.sharedRepository group
  

  a następnie ponownie uruchom rekurencyjne chmodi chgrp(patrz „Napraw uprawnienia” powyżej).

• System operacyjny nie interpretuje bitu setgid w katalogach jako „wszystkie nowe pliki i podkatalogi powinny dziedziczyć właściciela grupy”.

  Kiedy core.sharedRepositoryjest truelub group, Git korzysta z funkcji systemów operacyjnych GNU (np. Każdej dystrybucji Linuksa), aby mieć pewność, że nowo utworzone podkatalogi są własnością właściwej grupy (grupy, w której znajdują się wszyscy użytkownicy repozytorium). Ta funkcja jest udokumentowana w dokumentacji GNU coreutils :

  ... [Jeśli] ustawiony jest bit katalogu set-group-ID, nowo utworzone podfile dziedziczą tę samą grupę co katalog, a nowo utworzone podkatalogi dziedziczą bit set-group-ID katalogu nadrzędnego. ... [Ten mechanizm umożliwia] użytkownikom łatwiejsze udostępnianie plików, zmniejszając potrzebę korzystania chmodlub chownudostępniania nowych plików.

  Jednak nie wszystkie systemy operacyjne mają tę funkcję (jednym przykładem jest NetBSD). W przypadku tych systemów operacyjnych należy upewnić się, że wszyscy użytkownicy Git mają tę samą grupę domyślną. Alternatywnie możesz sprawić, aby repozytorium było zapisywane na całym świecie, uruchamiając git config core.sharedRepository world(ale bądź ostrożny - jest to mniej bezpieczne).

• System plików nie obsługuje bitu setgid (np. FAT). ext2, ext3, ext4 wszystkie obsługują bit setgid. O ile mi wiadomo, systemy plików, które nie obsługują bitu setgid, również nie obsługują koncepcji własności grupy, więc wszystkie pliki i katalogi będą własnością tej samej grupy (która grupa jest opcją montowania). W takim przypadku upewnij się, że wszyscy użytkownicy Git są w grupie, która jest właścicielem wszystkich plików w systemie plików.
• Nie wszyscy użytkownicy Git należą do tej samej grupy, która jest właścicielem katalogów repozytorium. Upewnij się, że właściciel grupy w katalogach jest poprawny i że wszyscy użytkownicy należą do tej grupy.

W systemie Ubuntu (lub dowolnym systemie Linux)

Z katalogu głównego projektu

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

Możesz powiedzieć, jaka powinna być twoja nazwa i twoja grupa, patrząc na uprawnienia do większości danych wyjściowych tej komendy ls -al

Uwaga: pamiętaj gwiazdę na końcu linii sudo

użyj następującego polecenia, działa jak magia

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

wpisz polecenie dokładnie tak, jak jest (z dodatkowymi spacjami i jedną kropką na końcu)

sudo chmod -R ug+w .;

Zasadniczo .git/objectsplik nie ma uprawnień do zapisu. Powyższa linia uprawnia do wszystkich plików i folderów w katalogu.

Chciałem tylko dodać moje rozwiązanie. Miałem repozytorium w systemie OS X, które posiadało root w niektórych katalogach, a Home (który jest moim katalogiem użytkownika) w innych, które spowodowały ten sam błąd wymieniony powyżej.

Na szczęście rozwiązanie było proste. Z terminala:

sudo chown -R Home projectdirectory

Dobrym sposobem na debugowanie jest to, kiedy następnym razem się zdarzy, SSH do zdalnego repozytorium, cd do folderu obiektów i wykonaj ls -al .

Jeśli zobaczysz 2-3 pliki z innym użytkownikiem: własność grupy niż to jest problem.

W przeszłości zdarzało mi się, że niektóre starsze skrypty mają dostęp do naszego repozytorium git i zwykle oznacza, że ​​inny (uniksowy) użytkownik pchnął / zmodyfikował pliki jako ostatni, a użytkownik nie ma uprawnień do nadpisywania tych plików. Należy stworzyć wspólną grupę git, że wszyscy użytkownicy git-włączone są i następnie rekurencyjnie Folder i jego zawartość tak, że jest to własność wspólna grupa jest grupą.chgrpobjectsgit

Powinieneś także dodać lepki bit do folderu, aby wszystkie pliki utworzone w folderze zawsze miały grupę git.

chmod g + s nazwa-katalogu

Aktualizacja: Nie wiedziałem o core.sharedRepository. Dobrze wiedzieć, choć prawdopodobnie robi to tylko powyższe.

Rozwiązane dla mnie ... właśnie to:

sudo chmod 777 -R .git/objects

Może się to łatwo zdarzyć, jeśli działałeś git initz innym użytkownikiem niż ten, którego planujesz użyć podczas wypychania zmian.

Jeśli ślepo zastosujesz się do instrukcji na [1], stanie się tak, ponieważ prawdopodobnie utworzyłeś użytkownika git jako root, a następnie natychmiast przeszedłeś do git init bez zmiany użytkownika pomiędzy.

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

Linux, macOS:

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

gdzie namejest twoja nazwa użytkownika i groupgrupa, do której należy twoja nazwa użytkownika.

Po dodaniu niektórych elementów ... zatwierdź je, a potem gotowe! HUK!! Zacznij wszystkie problemy ... Jak zauważyłeś, 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ć / wypchnąć te same pliki lub treść (git zachowuje oba jako 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ć na uwadze system uprawnień systemu operacyjnego, ponieważ w tym przypadku jesteś przez niego ograniczony. Aby lepiej zrozumieć problem, sprawdź folder 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 dla twoich użytkowników, nikt nigdy nie będzie mógł go 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 samodzielnie zmienić wszystkie uprawnienia, wykonując krok drugi, 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 dowiedzieć się, kim oni są :

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

Teraz ty i wszyscy właściciele plików, będziecie musieli zmienić uprawnienia do tych plików, wykonując:

$ chmod -R 774 .

Następnie musisz dodać nową właściwość, która jest równoważna z --shared = grupa wykonana dla nowego repozytorium, zgodnie z dokumentacją, dzięki czemu repozytorium można zapisać w grupie, wykonaj to:

$ git config core.sharedRepository group

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

W moim przypadku żadna z sugestii nie zadziałała. Korzystam z systemu Windows i działało to dla mnie:

• Skopiuj zdalne repozytorium do innego folderu
• Udostępnij folder i udziel odpowiednich uprawnień.
• Upewnij się, że możesz uzyskać dostęp do folderu z komputera lokalnego.
• Dodaj to repozytorium jako kolejne repozytorium zdalne w repozytorium lokalnym. (git remote add foo //SERVERNAME/path/to/copied/git )
• Push to foo. git push foo master. Czy zadziałało Świetny! Teraz usuń niedziałające repozytorium i zmień jego nazwę na dowolną wcześniej. Upewnij się, że uprawnienia i właściwość udostępniania pozostają takie same.

Uderzyłem ten sam problem. Czytając tutaj, zdałem sobie sprawę, że chodzi o uprawnienia do plików, o których mowa w wiadomości. Dla mnie poprawka dotyczyła:

/etc/inetd.d/git-gpv

Zaczynał git-daemon jako użytkownik „ nobody ”, więc brakowało mu uprawnień do zapisu.

# 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

(Wątpię, aby inni nazywali swój plik inetd conf git-gpv. Zwykle byłby bezpośrednio w /etc/inetd.conf)

Potrzebujesz wystarczających uprawnień do zapisu w katalogu, do którego wypychasz.

W moim przypadku: serwer Windows 2008

kliknij prawym przyciskiem myszy katalog git repo lub katalog nadrzędny.

Właściwości> karta Udostępnianie> Udostępnianie zaawansowane> Uprawnienia> upewnij się, że użytkownik ma odpowiednie prawa dostępu.

Możliwe, że przypadkowo zagnieżdżono repozytoria git

Istnieje również możliwość dodania innego lokalnego repozytorium z tym samym aliasem. Na przykład masz teraz 2 foldery lokalne nazywaneorigin tak, że podczas próby wypchnięcia zdalne repozytorium nie zaakceptuje poświadczeń.

Zmień nazwę aliasów lokalnego repozytorium, możesz kliknąć ten link https://stackoverflow.com/a/26651835/2270348

Może możesz zostawić 1 lokalne repozytorium, które ci się podoba, origina inni zmienią ich nazwy, na przykład od origindo anotherorigin. Pamiętaj, że to tylko aliasy, a wszystko, co musisz zrobić, to zapamiętać nowe aliasy i ich odpowiednie odległe gałęzie.

Pracuje dla mnie

sudo chmod -R g+rwX .

Dostałem to, wciągając się w projekt Rstudio. Zrozumiałem, że zapomniałem zrobić:

sudo rstudio

podczas uruchamiania programu. Ponieważ mam inny błąd, muszę go wykonać:

sudo rstudio --no-sandbox

Użyj sudo do zatwierdzenia -m

• git dodaj -A
• sudo git commit -m "Użyj sudo do zatwierdzenia -m"
• git push origin nazwa_gałęzi

Problem występował w przypadku zdalnego repozytorium w udziale Samba; Udało mi się wyciągnąć z tego pilota, ale nie udało mi się go naciskać.

Przyczyną błędu były nieprawidłowe dane uwierzytelniające w moim ~/.smbcredentialspliku.