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

591

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.

skaz
źródło
Dostałem ten błąd po przypadkowym git addi git commit-ing jako użytkownik root. Naprawiłem to z odpowiedzią na git resetto pytanie, aby naprawić .gituprawnienia do katalogu.
StockB
Jak mogę dowiedzieć się, który obiekt próbował utworzyć (podczas ręcznego debugowania takich problemów z uprawnieniami)? Komunikat o błędzie jest zbyt niejasny.
mirabilos
Wystąpił ten błąd podczas kopiowania wklejania innego pliku .git za pomocą sudo. dlatego pliki miały sudo sudo jako nazwę i grupę.
Vincent

Odpowiedzi:

863

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.
Richard Hansen
źródło
1
@Richard Hansen - Naprawdę nie wiem, co masz na myśli przez wymuszanie własności. Patrzę na mężczyznę z chmod, ale nie wiem wystarczająco dużo o tym, żeby słowa miały sens :) Jakieś wskazówki?
skaz
7
@GiH: Nic nie dostaniesz, jeśli jest rozbrojony (to samo co falselub umask). Zobacz git help configpo więcej szczegółów.
Richard Hansen
10
Musiałem wydać git pushza pomocą konta root w moim katalogu roboczym. Odkryłem, że właścicielem niektórych plików repozytorium git jest root ( -r--r--r--. 1 root root 6380 5月 25 12:39 9b44bd22f81b9a8d0a244fd16f7787a1b1d424) zgodnie z tą odpowiedzią.
LiuYan 刘 研
3
@MattBrowne: Pamiętaj, że jest to wielka Xlitera, a nie małe litery x. Wielka Xoznacza „ustaw, S_IXGRPjeśli plik jest katalogiem (lub jeśli S_IX*ustawiony jest inny bit)”, więc nie sprawi, że wszystkie pliki będą wykonalne. Może to być niepotrzebne, ale może nie, jeśli w przeszłości core.sharedRepositorybyło to ustawione 0600.
Richard Hansen
2
@francoisromain: Linia ta ustawia bit setgid we wszystkich katalogach. Zobacz gnu.org/software/coreutils/manual/html_node/…
Richard Hansen
440

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

Frotte
źródło
7
Działa świetnie! Tak, z jakiegoś powodu niektórym folderom przypisano inną nazwę i grupę (root).
Peter Arandorenko
2
Dostaję:Sorry, user myuser is not allowed to execute '/bin/chown
Francisco Corrales Morales
*Wykonana cała różnica. Dzięki.
Bradley Flood
5
Mój problem polegał na tym, że kiedyś zrobiłem „ściągnięcie git” jako root, co myślę, że spieprzyłem uprawnienia ... możesz to sprawdzić wykonującls .git
rogerdpack
Dzięki za szybkie rozwiązanie!
helvete,
74

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)

Code_Worm
źródło
6
Działa jak marzenie!
doncadavona,
1
niesamowite! działał doskonale na moim komputerze Mac
Sachin Khot
To mi też pomogło! Dzięki.
Horvath Adam
Rzeczywiście działał jak magia! Dzięki!
Kumar Manish
49

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.

Rajendra kumar Vankadari
źródło
2
To działało dla mnie. Przyjęta odpowiedź niestety nie. Dzięki Rajendra!
odwołał
27

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
Brandon
źródło
To samo mi się przydarzyło. Nie mogę zrozumieć, w jaki sposób niektóre obiekty uzyskały prawa roota, ale tak się stało.
vy32,
18

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.

Mauvis Ledford
źródło
15

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

sudo chmod 777 -R .git/objects
GUSTAVO BERBERT
źródło
21
Chmod 777nie jest zalecane, ponieważ udostępnia cały plik reszcie świata, narażając maszynę na niebezpieczeństwo
Elena,
23
Jeśli twoja rada jest następująca chmod 777: 99 razy na 100 nie rozumiesz problemu i prawdopodobnie spowodujesz więcej problemów niż pomożesz rozwiązać. Jak pokazuje powyższa zaakceptowana odpowiedź, problem ten nie różni się.
jonatan
Dlaczego nie proponujecie akceptowalnej odpowiedzi, a zamiast tego mówicie, że to zły wybór?
Giovani,
2
Ponieważ pomimo tego, że na stronie znajdują się dopuszczalne odpowiedzi, ta niedopuszczalna odpowiedź wciąż istnieje.
Te JoE
sudo chmod -R 777 .git / objects
Nabeel Ahmed
9

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

Gitzor
źródło
7

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.

Afshin Mehrabani
źródło
5

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

helmedeiros
źródło
Miałem to samo username:groupnamedla mojego, ale kiedy spróbowałem chmod -R 774 ., mogłem wtedy z git add --allpowodzeniem biegać .
John Skilbeck,
3

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.
Halil Kaskavalci
źródło
1
W moim przypadku po prostu skopiowanie folderu lokalnego do nowego folderu, usunięcie starego i zmiana nazwy nowego na starą nazwę rozwiązały problemy z uprawnieniami.
mgiuffrida
2

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)

GraemeV
źródło
1

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.

Fuyu Persimmon
źródło
1

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

IliasT
źródło
1

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.

Huey Mataruse
źródło
0

Pracuje dla mnie

sudo chmod -R g+rwX .
Nitin.
źródło
0

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
Timothy Pollington
źródło
0

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
oparam
źródło
0

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.

Josh
źródło