Git Push Error: autorizzazione insufficiente per l'aggiunta di un oggetto al database del repository

Quando provo a passare a un telecomando git condiviso, viene visualizzato il seguente errore: insufficient permission for adding an object to repository database

Quindi ho letto di una correzione qui: Correzione Funzionava per il push successivo, poiché tutti i file appartenevano al gruppo corretto, ma la volta successiva che qualcuno ha apportato una modifica ha apportato un nuovo elemento nella cartella degli oggetti con il gruppo predefinito come gruppo. L'unica cosa che mi viene in mente è di cambiare tutto il gruppo predefinito dello sviluppatore per gli elementi che fanno il check-in, ma sembra un hack. Qualche idea? Grazie.

Autorizzazioni di riparazione

Dopo aver identificato e corretto la causa sottostante (vedi sotto), ti consigliamo di riparare le autorizzazioni:

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

Nota se vuoi che tutti siano in grado di modificare il repository, non hai bisogno di chgrpe vorrai cambiare il chmod insudo chmod -R a+rwX .

Se non risolvi la causa sottostante, l'errore continuerà a ripresentarsi e dovrai continuare a ripetere i comandi precedenti.

Cause sottostanti

L'errore potrebbe essere causato da uno dei seguenti:

• Il repository non è configurato per essere un repository condiviso (vedere core.sharedRepositoryin git help config). Se l'output di:

  git config core.sharedRepository
  

  non è groupo trueo 1o qualche maschera, prova a eseguire:

  git config core.sharedRepository group
  

  e quindi rieseguire il ricorsivo chmode chgrp(vedere "Autorizzazioni di riparazione" sopra).

• Il sistema operativo non interpreta un bit setgid nelle directory come "tutti i nuovi file e sottodirectory dovrebbero ereditare il proprietario del gruppo".

  Quando core.sharedRepositoryè trueo group, Git si affida a una funzionalità dei sistemi operativi GNU (ad esempio, ogni distribuzione Linux) per garantire che le sottodirectory appena create siano di proprietà del gruppo corretto (il gruppo in cui si trovano tutti gli utenti del repository). Questa funzione è documentata nella documentazione di GNU coreutils :

  ... [Se] è impostato un bit set-group-ID di una directory, i file secondari appena creati ereditano lo stesso gruppo della directory e le sottodirectory appena create ereditano il bit ID gruppo-set della directory padre. ... [Questo meccanismo consente] agli utenti di condividere i file più facilmente, riducendo la necessità di utilizzare chmodo chowncondividere nuovi file.

  Tuttavia, non tutti i sistemi operativi dispongono di questa funzione (NetBSD ne è un esempio). Per quei sistemi operativi, dovresti assicurarti che tutti i tuoi utenti Git abbiano lo stesso gruppo predefinito. In alternativa, è possibile rendere il repository scrivibile dal mondo eseguendo git config core.sharedRepository world(ma fare attenzione, questo è meno sicuro).

• Il file system non supporta il bit setgid (ad esempio, FAT). ext2, ext3, ext4 supportano tutti il ​​bit setgid. Per quanto ne so, i file system che non supportano il bit setgid, inoltre, non supportano il concetto di proprietà del gruppo, quindi tutti i file e le directory saranno comunque di proprietà dello stesso gruppo (quale gruppo è un'opzione di montaggio). In questo caso, assicurati che tutti gli utenti Git siano nel gruppo che possiede tutti i file nel file system.
• Non tutti gli utenti Git appartengono allo stesso gruppo proprietario delle directory del repository. Assicurarsi che il proprietario del gruppo nelle directory sia corretto e che tutti gli utenti siano in quel gruppo.

Per Ubuntu (o qualsiasi Linux)

Dalla radice del progetto,

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

Puoi dire quale dovrebbe essere il tuo nome e il tuo gruppo guardando le autorizzazioni sulla maggior parte dell'output di quel comando ls -al

Nota: ricorda la stella alla fine della riga sudo

usa il seguente comando, funziona come per magia

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

digitare il comando esattamente come è (con spazi extra e un punto alla fine)

sudo chmod -R ug+w .;

Fondamentalmente, il .git/objectsfile non ha i permessi di scrittura. La riga sopra concede l'autorizzazione a tutti i file e le cartelle nella directory.

Volevo solo aggiungere la mia soluzione. Ho avuto un repository su OS X che aveva la proprietà di root su alcune directory e Home (che è la mia directory utente) su altri che ha causato lo stesso errore elencato sopra.

La soluzione è stata semplice per fortuna. Dal terminal:

sudo chown -R Home projectdirectory

Un buon modo per eseguire il debug è la prossima volta che succede, SSH nel repository remoto, cd nella cartella oggetti e fare un ls -al.

Se vedi 2-3 file con utenti diversi: la proprietà del gruppo di questo è il problema.

Mi è successo in passato con alcuni script legacy che accedono al nostro repository git e di solito significa che un altro utente (unix) ha spinto / modificato i file per ultimo e il tuo utente non ha i permessi per sovrascrivere quei file. Dovresti creare un gruppo git condiviso in cui si trovano tutti gli utenti abilitati per git e quindi ricorsivamente chgrpla objectscartella e i suoi contenuti in modo che la proprietà del gruppo sia il gitgruppo condiviso .

È inoltre necessario aggiungere un bit appiccicoso alla cartella in modo che tutti i file creati nella cartella abbiano sempre il gruppo di git.

chmod g + s nome-directory

Aggiornamento: non sapevo di core.sharedRepository. Buono a sapersi, anche se probabilmente fa solo quanto sopra.

Risolto per me ... solo questo:

sudo chmod 777 -R .git/objects

Ciò può accadere facilmente se si è eseguito git initcon un utente diverso da quello che si prevede di utilizzare quando si spingono le modifiche.

Se segui ciecamente le istruzioni su [1] ciò accadrà poiché probabilmente hai creato git-user come root e poi sei passato immediatamente a git init senza cambiare utente nel mezzo.

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

Linux, macOS:

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

dov'è il nametuo nome utente ed groupè il gruppo a cui appartiene il tuo nome utente.

Dopo aver aggiunto alcune cose ... impegnale e dopo tutto finito spingilo! SCOPPIO!! Inizia tutti i problemi ... Come dovresti notare, ci sono alcune differenze nel modo in cui sono stati definiti sia i progetti nuovi che quelli esistenti. Se un'altra persona prova ad aggiungere / eseguire il commit / push degli stessi file o contenuti (git mantiene entrambi gli stessi oggetti), riscontreremo il seguente errore:

$ 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

Per risolvere questo problema, devi tenere presente il sistema di autorizzazioni del sistema operativo, poiché in questo caso sei limitato da esso. Capisci meglio il problema, vai avanti e controlla la cartella del tuo oggetto git (.git / objects). Probabilmente vedrai qualcosa del genere:

<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

* Nota che le autorizzazioni di quel file sono state concesse solo ai tuoi utenti, nessuno potrà mai cambiarlo ... *

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

RISOLUZIONE DEL PROBLEMA

Se disponi dell'autorizzazione superutente, puoi andare avanti e modificare tutte le autorizzazioni da solo utilizzando il passaggio due, in ogni caso dovrai chiedere a tutti gli utenti con oggetti creati con i loro utenti, utilizzare il comando seguente per sapere chi sono :

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

Ora tu e tutti gli utenti proprietari del file dovrete modificare i permessi di questi file, facendo:

$ chmod -R 774 .

Dopodiché dovrai aggiungere una nuova proprietà che è equivalente a --shared = group fatto per il nuovo repository, secondo la documentazione, questo rende il repository scrivibile dal gruppo, fallo eseguire:

$ git config core.sharedRepository group

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

Nel mio caso nessuno dei suggerimenti ha funzionato. Sono su Windows e questo ha funzionato per me:

• Copia il repository remoto in un'altra cartella
• Condividi la cartella e concedi le autorizzazioni appropriate.
• Assicurati di poter accedere alla cartella dal tuo computer locale.
• Aggiungere questo repository come un altro repository remoto nel repository locale. ( git remote add foo //SERVERNAME/path/to/copied/git)
• Spingere verso foo. git push foo master. Ha funzionato? Grande! Ora cancella il repository non funzionante e rinominalo in qualunque cosa fosse prima. Assicurarsi che le autorizzazioni e la proprietà di condivisione rimangano le stesse.

Ho riscontrato questo stesso problema. Leggendo qui ho capito che erano i permessi dei file a cui si riferiva il messaggio. La correzione, per me, era in:

/etc/inetd.d/git-gpv

Stava avviando git-daemon come utente " nessuno ", quindi mancava il permesso di scrittura.

# 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

(Dubito che altri chiamino il loro file di configurazione inetd git-gpv. Comunemente sarebbe direttamente in /etc/inetd.conf)

Sono necessarie le autorizzazioni di scrittura sufficienti per la directory in cui si sta spingendo.

Nel mio caso: server Windows 2008

fare clic con il tasto destro sulla directory git repo o sulla directory principale.

Proprietà> scheda Condivisione> Condivisione avanzata> Autorizzazioni> assicurarsi che l'utente disponga dei diritti di accesso appropriati.

Potresti avere dei repository git nidificati accidentalmente

È anche possibile che sia stato aggiunto un altro repository locale con lo stesso alias. Ad esempio, ora hai 2 cartelle locali indicate come origintali quando provi a eseguire il push, il repository remoto non accetterà le tue credenziali.

Rinominare gli alias del repository locale, è possibile seguire questo collegamento https://stackoverflow.com/a/26651835/2270348

Forse puoi lasciare 1 repository locale di tuo gradimento come origine gli altri li rinominano ad esempio da origina anotherorigin. Ricorda che questi sono solo alias e tutto ciò che devi fare è ricordare i nuovi alias e i loro rispettivi rami remoti.

Per me va bene

sudo chmod -R g+rwX .

Ho capito quando mi sono avvicinato a un progetto Rstudio. Mi sono reso conto di aver dimenticato di fare:

sudo rstudio

all'avvio del programma. Infatti, dato che c'è un altro bug che ho, devo davvero fare:

sudo rstudio --no-sandbox

Usa sudo per commit -m

• git aggiungi -A
• sudo git commit -m "Usa sudo per commit -m"
• git push origin nome_directory

Stavo riscontrando questo problema con un repository remoto su una condivisione Samba; Ho tirato con successo da questo telecomando, ma ho fallito quando lo spingevo.

La causa dell'errore erano le credenziali errate nel mio ~/.smbcredentialsfile.