git: nu se poate face push (eroare de despachetare) legată de probleme de permisiune (Programare, Linux, Git)

Max Williams a intrebat.

Am această problemă atunci când încerc să împing în 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>'

Am mai avut acest lucru înainte sporadic și întotdeauna a trebuit să o rezolvăm prin fiecare utilizator sshing la repo și setarea permisiunilor de grup pe toate fișierele de acolo cu

chmod -R g+w *

Aceasta nu a fost niciodată o soluție satisfăcătoare, iar acum ne-a mușcat de fund, deoarece unul dintre băieți este plecat și nimeni nu știe parola utilizatorului repo-ului său. Așa că încerc să o rezolv cum trebuie.

Eroarea pare să apară atunci când cineva încearcă să impună o modificare care va altera un dir repo care este deținut de un alt utilizator (de aici și setarea opțiunii de scriere în grup de mai sus). Am căutat puțin pe Google și am găsit câteva soluții discutate (niciuna dintre ele nu a funcționat pentru mine)

1) asigurați-vă că grupul cu care sunt partajate repo dirs este grupul principal al fiecărui utilizator (cred că este deja cazul: fiecare utilizator are un singur grup, deci acela trebuie să fie grupul său principal, nu?)

2) setarea git repo core.sharedRepository, așa cum este detaliat aici: Git: Can’t push from one computerAm schimbat acest lucru, dar nu a făcut nicio diferență. Trebuie să reîncarc configurația sau ceva de genul acesta pentru a efectua efectiv modificarea?

Iată cum arată configurația mea repo atm:

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

Mulțumesc pentru orice sfat sau sugestie!max

Comentarii

  • Poți furniza un repo de testare minim care produce această problemă? Pot să o obțin întotdeauna dacă am un .GIT director (cu majuscule) în depozit. –  > Por Ciro Santilli新疆棉花TRUMP BAN BAD.
  • Acest lucru poate fi cauzat și de faptul că discul este plin și nu este neapărat o problemă de permisiuni! –  > Por GH05T.
13 răspunsuri
spadeworkers

O modalitate mai simplă de a face acest lucru este să adăugați un script post-recepție care execută commanda chmod după fiecare push la repo-ul „hub” de pe server. Adăugați următoarea linie la hooks/post-receive în interiorul folderului git de pe server:

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

Comentarii

  • Mulțumesc pentru acest răspuns, m-am confruntat cu aceeași problemă și nu am fost dispus să configurez un întreg pachet de gestionare a repo-urilor doar pentru a rezolva această problemă. –  > Por Kelly.
  • Acest script post-receve a funcționat pentru mine: chown -R git:git /home/git/repositories/myrepo.git/objects/ – –  > Por fjsjj.
  • ar putea fi și o problemă de proprietar, dacă unele foldere/fișiere din depozitul la distanță au fost modificate/create de un alt utilizator la distanță, diferit de cel de la pusher –  > Por Fedir RYKHTIK.
  • Eu personal am folosit întotdeauna același utilizator pentru administrator, dar proprietarul unor obiecte părea să fi fost modificat. I chowned -R pentru a remedia situația –  > Por Pierre de LESPINAY.
Jason Robinson

Am avut această eroare timp de două săptămâni, iar majoritatea soluțiilor au indicat „chmod -R” ca răspuns, din păcate pentru mine, depozitele mele git (locale / la distanță / partajate – cu echipa) erau toate pe sistemul de operare Windows și, chiar dacă chmod -Rv a arătat toate fișierele schimbate în „rwxrwxrwx”, un „ls -l” ulterior a arătat toate fișierele ca fiind „rwxr-xr-x” și eroarea s-a repetat. În cele din urmă am văzut această soluție de Ariejan de Vroom. A funcționat și am putut cu toții să tragem și să împingem din nou.

Atât pe depozitul local (cel care are probleme cu împingerea), cât și pe cel de la distanță, rulați următoarele comenzi:

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

În altă ordine de idei, am încercat să folosesc permisiunile native de fișiere / ACL din Windows și chiar am recurs la ridicarea utilizatorului cu probleme la Administrator, dar nimic din toate acestea nu a părut să ajute. Nu sunt sigur dacă mediul este important, dar ar putea ajuta pe cineva cu o configurație similară – membrul echipei cu probleme și la distanță (Windows Server 2008 R2 Standard), localul meu (Windows 7 VM).

Comentarii

  • Există un caz pentru această eroare atunci când există o corupție a sistemului de fișiere git și aceste instrucțiuni au ajutat la corectarea acesteia. Mulțumiri –  > Por nkadwa.
  • @nkadwa Mă bucur că acest lucru v-a putut ajuta –  > Por Jason Robinson.
  • deoarece acesta este singurul răspuns care se referă și la Windows. Am avut exact aceeași problemă pe Windows 10 ca utilizator neprivilegiat. O simplă git pull a rezolvat-o. –  > Por Markus.
Alastair

Este o eroare de permisiune. Modul cel mai potrivit și sigur pentru mine a fost următorul adăugarea utilizatorilor la un grup suplimentar de care repo. este deținut (sau viceversa):

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

Comentarii

  • Nu ar trebui să fie usermod -G -a ... pentru a evita ca utilizatorul să fie eliminat din toate grupurile, cu excepția git? –  > Por chris.
  • Woah…nu pot să cred că am ratat asta și sper că nu au existat repercusiuni confuze pentru cei care au votat în sus. Mulțumesc, @chris –  > Por Alastair.
sjas

În cazul în care altcineva este blocat cu acest lucru: înseamnă doar că permisiunile de scriere sunt greșite în repo-ul pe care îl împingeți. Du-te și fă chmod -R astfel încât utilizatorul cu care accesezi serverul git să aibă acces la scriere.

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

Pur și simplu funcționează.

Comentarii

  • Vă rugăm să postați conținutul răspunsurilor externe pe stackoverflow: pentru cazul în care acel url extern nu funcționează. –  > Por ThorSummoner.
  • După cum a menționat @ThorSummoner, este mai bine să puneți conținutul de pe blog în acest post. Linkul este acum depășit. –  > Por colidyre.
aradil

În cazul meu, această eroare a apărut atunci când nu mai aveam spațiu pe telecomandă.

Trebuia doar să citesc restul mesajului de eroare:

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

Cameron Skinner

Folosesc gitosis pentru gestionarea acestui tip de lucruri. Gitosis are un singur utilizator (numit de obicei „git”) care deține toate depozitele și folosește controlul accesului pe bază de cheie publică la fiecare repo. S-ar putea să nu se potrivească configurației dumneavoastră, dar probabil că merită verificat (fără joc de cuvinte).

Comentarii

  • Există, de asemenea, gitolite (github.com/sitaramc/gitolite), care este un fel de versiune actualizată și îmbunătățită a lui gitosis. –  > Por ebneter.
  • Mulțumesc, băieți. Dar trebuie să-mi reconstruiesc repo-ul de la zero folosind gitosis/gitolite? –  > Por Max Williams.
  • Nu. Pur și simplu împingeți capul existent în repo-ul gitosis sau copiați directorul repo-ului dvs. în cel creat de gitosis. –  > Por Cameron Skinner.
Henning Lee

În ceea ce privește eroarea de permisiune care utilizează depozitul git pe instanța AWS, am rezolvat-o cu succes prin crearea unui grup și atribuirea acestuia la dosarul depozitului în mod recursiv (-R), și acordarea dreptului de scriere acestui grup, apoi atribuirea utilizatorului implicit al instanței aws (ec2-user sau ubuntu) acestui grup.

1. Creați un grup cu numele share_group sau altceva

     sudo groupadd share_group

2. Schimbați folderul de depozit din grupul „root” în „share_group

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

3. adăugați autoritatea de scriere la share_group

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

4. Ultimul pas este să atribuiți utilizatorul curent – utilizatorul implicit la conectare (în mod implicit ec2 este ‘ec2-user’, utilizatorul instanței ubuntu este ‘ubuntu’ în ubuntu pe aws) la share_group. Eu folosesc o instanță ubuntu pe aws, deci utilizatorul meu implicit este ubuntu.

     sudo usermod -a -G share_group ubuntu

Apropo, pentru a vedea proprietatea dosarului sau a fișierului, trebuie doar să tastați:

    ls -l  /path/to/your/repository

Output:

    drwxr-x--x  2 root shared_group

(explicația vă rugăm să vedeți:https://wiki.archlinux.org/index.php/File_permissions_and_attributes).

După pasul 3, veți vedea

    drwx--x--x  2 root root

s-a schimbat în

    drwxr-x--x  2 root share_group 

În acest caz, nu am atribuit utilizatorului „ubuntu” grupul root, din considerente de securitate. Puteți încerca să atribuiți utilizatorul implicit la root conform pasului 4 (săriți doar peste primii 3 pași


Într-un alt mod, am încercat soluția prin :

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

Nu a funcționat pentru mine, cred că ar trebui să fie motivul pentru care dosarul meu de depozit aparține utilizatorului root, nu utilizatorului Ubuntu, iar ‘git’ utilizează în mod implicit utilizatorul implicit (ec2-user sau Ubuntu user. Puteți încerca să schimbați utilizatorul și să testați.


În cele din urmă, codul de mai jos funcționează cu siguranță pentru mine, dar 777 nu este bun pentru securitate

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

Comentarii

  • sudo chmod -R 777 /path/to/your/repo a funcționat 🙂 –  > Por TrueCode.
jpswain

Și eu am avut probleme cu acest lucru, crezând că gitolite-admin-ul meu de la distanță era corupt sau ceva în neregulă.

Configurația mea este un laptop Mac OS X (10.6.6) cu un server Ubuntu 10 de la distanță cu gitolite.

S-a dovedit că problema a fost la mine local checkout al gitolite-admin.

În ciuda erorii „unpack failed”, s-a dovedit că problema era locală.

Mi-am dat seama de acest lucru verificându-l din nou ca gitolite-admin2, făcând o modificare și împingând.

Voila! A funcționat!

Comentarii

  • Pentru mine, problema era tot în depozitul local (probabil pentru că am folosit o versiune mai veche de git pe structurile .git ale unei versiuni mai noi). git push nu a funcționat, dar git clone a funcționat, așa că am clonat depozitul local și apoi am transplantat noul .git în depozitul local. Mulțumesc pentru indiciu! –  > Por Robert Hensing.
cmc

Această problemă poate apărea și după actualizările Ubuntu care necesită o repornire.

În cazul în care fișierul /var/run/reboot-required există, faceți sau programați o repornire.

dariush

Dacă mai contează, am avut aceeași problemă pe propriul meu VPS și a fost cauzată de spațiul redus pe hard disk pe VPS. Confirmat de df -h comandă și după ce am curățat hard disk-ul VPS-ului meu; problema a dispărut.

Noroc.

Hrushikesh

Am primit o eroare similară și vă rog să vedeți mai jos cum am rezolvat-o.

Structura directorului meu: /opt/git/proiect.git și utilizatorul git este git

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

chown cu opțiunea -R schimbă recursiv proprietatea și și grupul (din moment ce am tastat git:git în comanda de mai sus) al directorului curent. chown -R este necesar deoarece git schimbă multe fișiere din interiorul directorului git atunci când faceți push la depozit.

Mark E. Hamilton

Acolo unde lucrez eu, folosim această metodă în toate depozitele noastre de câțiva ani fără probleme (cu excepția cazurilor în care creăm un nou depozit și uităm să îl configurăm în acest mod):

  1. Setați „sharedRepository = true” în secțiunea „[core]” din fișierul de configurare.
  2. Schimbați id-ul de grup al depozitului cu un grup partajat de toți utilizatorii care au voie să facă push către acesta:

    chgrp -R shared_group /git/our_repos
    chmod -R g+w /git/our_repos
    
  3. Setați bitul setgid pe toate directoarele din depozit, astfel încât noile fișiere/directoare să păstreze același grup:

    find /git/our_repos -type d -exec chmod g+s {} +
    
  4. Adăugați această linie la cârligul de pre-recepție din depozit pentru a vă asigura că permisiunile noilor fișiere permit citirea/scrierea în grup:

    umask 007
    

MobileMon

Pentru mine este o problemă de permisiuni:

Pe serverul git, rulați această comandă în directorul repo.

sudo chmod -R 777 theDirectory/

Comentarii

  • Nu folosiți niciodată 777. În schimb, creați un utilizator cu comanda adduser [username], apoi faceți din acest utilizator proprietarul directorului cu chown -R [user]:[group] [directory], apoi setați directorul astfel încât să poată fi scris de către proprietar, deci chmod -R 775 sau ceva de genul acesta. Prima cifră guvernează permisiunile utilizatorului, a doua guvernează permisiunile grupului, iar a treia guvernează permisiunile tuturor celorlalți. –  > Por kloddant.

Tags:,