Errore durante l'invio a GitHub - autorizzazione insufficiente per l'aggiunta di un oggetto al database del repository

Ricevo un errore insolito mentre provavo a fare un "git push" sul mio repository GitHub:

Conteggio degli oggetti: 8, fatto.
Compressione delta mediante 2 thread.
Comprimere oggetti: 100% (4/4), fatto.
Scrivere oggetti: 100% (5/5), 1,37 KiB, fatto.
Totale 5 (delta 2), riutilizzato 0 (delta 0)
errore: autorizzazione insufficiente per l'aggiunta di un oggetto al database del repository ./objects

fatale: impossibile scrivere l'oggetto
errore: unpack-object è uscito con il codice di errore 128
errore: decompressione non riuscita: uscita anomala di decompressione-oggetti
A git@github.com: bixo / bixo.git
 ! [remoto rifiutato] master -> master (n / a (errore di decompressione))
errore: impossibile inviare alcuni riferimenti a 'git@github.com: bixo / bixo.git'

• Dopo un clone pulito da GitHub, posso modificare / aggiungere / commit / push un file modificato.
• Se poi lo ripeto una seconda volta, visualizzo l'errore sopra riportato.
• Posso spingere bene su altri repository GitHub.
• Ho controllato i permessi di file / directory dalla mia parte e sembrano OK.
• Sto eseguendo git 1.6.2.3 su Mac OS X 10.5.8

Il repository sopra è stato la fonte del mio divertimento per una precedente domanda Stack Overflow ( SO 1904860 ), quindi forse il repository GitHub è stato danneggiato. L'unico problema simile che ho riscontrato tramite la ricerca è stato un problema di decompressione fallito segnalato su github. Qualcun altro ha riscontrato questo problema prima, specialmente quando non si utilizza GitHub?

Quando vedi questo errore al di fuori di github, ecco un rimedio.

Ottenuto da: 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

Dopo questo il demone git dovrebbe usare i permessi del file di gruppo quando scrive su .git / objects.

Di solito questo problema è causato da autorizzazioni utente e di gruppo errate sul file system dei server Git. Il repository git deve essere di proprietà dell'utente e anche del suo gruppo.

Esempio:

Se il tuo utente si chiama "git", il suo gruppo "gitgroup" e la posizione del repository Git è: git@mygitserverxyz.com: percorso / to / repo.git

quindi fai un:

sudo chown -R git: percorso gitgroup / to / repo.git /

Ciò ha risolto l'errore di autorizzazione insufficiente git per me.

sudo chmod 777 -R .git/objects

Questo è successo a me quando ho provato a farlo git pull. Alcune analisi hanno mostrato che qualcuno si era impegnato con root in passato, creando in tal modo alcuni oggetti con proprietà root in .git/objects.

Quindi ho corso

cd <repo>
la .git/objects/

e che mostrava la rootproprietà di alcuni oggetti (directory) come questo:

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

Poi ho corso

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

e ha funzionato!

Ovviamente stavo sostituendo l' utente con il mio vero utente.

Niente di quanto sopra ha funzionato per me. Un paio d'ore dopo ho trovato il motivo del problema: ho usato un URL repo del tipo

ssh://git@example.com/~git/repo.git

Purtroppo ho archiviato una sessione di stucco con il nome example.comche è stato configurato per accedere come utente myOtherUser.

Quindi, mentre pensavo che git si connettesse all'host example.comcon l'utente 'git', Git / TortoiseGit si è connesso alla sessione di stucco example.comche utilizza l'utente myOtherUser. Questo porta allo stesso identico..insufficient permission.. errore (perché entrambi gli utenti appartengono a gruppi diversi).

Soluzione: rinominare la sessione di stucco example.cominmyOtherUse@example.com

chmod dovrebbe essere chown, quindi la linea corretta è:

sudo chown -R gituser:gituser objects

Stranamente, ho avuto questo problema su un clone del repository che avevo, ma non un altro che avevo. Oltre a ri-clonare il repository (cosa che un collega ha fatto per aggirare con successo questo problema), sono riuscito a fare un "reset git" al commit che avevo prima dell'inizio degli errori. Quindi ho riconsegnato le modifiche e sono stato in grado di spingere con successo dopo. Quindi, nonostante tutte le indicazioni, c'era un problema sul server, in questo caso apparentemente era indicativo di qualche stranezza nel repository locale.

Stavo ottenendo questo errore perché ogni volta che un utente inviava un po 'di contenuto, il gruppo del file cambiava all'utente. E poi, se un altro utente ha provato a eseguire il push nel repository, ha causato un errore di autorizzazione e il push è stato rifiutato. Pertanto, è necessario chiedere al proprio amministratore di sistema di modificare le impostazioni del repository in modo che il gruppo di qualsiasi file nel repository non venga modificato per qualsiasi push da qualsiasi utente.

Per evitare tale problema, assicurarsi che quando si inizializza il repository git, utilizzare il comando "git init --shared = group".

Se ancora questo errore in seguito dopo impostato le autorizzazioni, potrebbe essere necessario modificare la maschera di creazione. Abbiamo scoperto che i nostri nuovi commit (cartelle sotto gli oggetti) erano ancora in fase di creazione senza autorizzazione di scrittura di gruppo, quindi solo la persona che li aveva commessi poteva spingere nel repository.

Abbiamo risolto il problema impostando umask degli utenti SSH su 002 con un gruppo appropriato condiviso da tutti gli utenti.

per esempio

umask 002

dove lo 0 centrale consente la scrittura di gruppo per impostazione predefinita.

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 delle autorizzazioni del sistema operativo, poiché in questo caso sei limitato da esso. Per capire 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à equivalente a --shared = group fatto per il nuovo repository, secondo la documentazione, questo rende il repository scrivibile dal gruppo, fallo eseguendo:

$ git config core.sharedRepository group

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

Prova a fare quanto segue:

Vai al tuo server

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

Quindi vai alla tua copia di lavoro (repository locale) e riconfezionala per git repack master

Funziona perfettamente con me.

puoi usarlo

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

sudo su root

chown -R user:group dir

Il dir è il tuo repository git.

Quindi fa:

git pull origin master

Vedrai cambiamenti sugli commit da parte di altri.

 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 - risulta che si è verificato un problema con le autorizzazioni su GitHub durante il fork di emi / bixo su bixo / bixo. Una volta risolti questi problemi, Tekkub ha ripreso a funzionare.

Poiché l'errore riguarda i permessi sulla cartella degli oggetti, ho fatto un chown direttamente sulla cartella degli oggetti e ha funzionato per me.

Questo funziona:

sudo chmod -R gituser.gituser objects

Immagino che molti come me finiscano in forum come questo quando si verifica il problema git come descritto sopra. Tuttavia, ci sono così tante cause che possono portare al problema che voglio solo condividere ciò che ha causato i miei problemi per gli altri ad imparare come ho già imparato dall'alto.

Ho i miei repository su un NAS Linux da sitecom (Non comprare mai NAS da Sitecom, pleeaaase). Ho un repository qui clonato su molti computer ma a cui improvvisamente mi è stato negato di spingermi. Di recente ho installato un plug-in in modo che il mio NAS potesse fungere da server squeezebox.

Questo server cerca i media da condividere. Quello che non sapevo era che, possibile a causa di un bug, il server cambia le impostazioni dell'utente e del gruppo in squeeze: utente per tutti i file in cui si trova. E questo è TUTTI i file. In tal modo alterando i diritti che ho dovuto spingere.

Il server è scomparso e vengono ripristinate le impostazioni dei diritti corrette e tutto funziona perfettamente.

ero solito

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

Dove myuser e mygroup fuori rotta devono essere sostituiti con le impostazioni appropriate per il proprio sistema. prova git: git o gituser: gituser o qualcos'altro che ti potrebbe piacere.,

Controlla il repository: $ git remote -v

origin  ssh://git@example.com:2283/srv/git/repo.git (fetch)
origin  ssh://git@example.com:2283/srv/git/repo.git (push)

Nota che c'è una sottostringa 'git @' qui, indica a git di autenticarsi come nome utente 'git' sul server remoto. Se si omette questa riga, git eseguirà l'autenticazione con un nome utente diverso, quindi si verificherà questo errore.

Nel mio caso non c'erano autenticazioni unificate (ad esempio all'interno del dominio + servizio simile a AD) tra la mia macchina e il server virtuale git. Pertanto, gli utenti e il gruppo git sono locali per il server virtuale. Nel mio caso il mio utente remoto (che utilizzo per accedere al server remoto) non è stato aggiunto al gruppo git remoto.

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

Dopodiché controlla le autorizzazioni come è descritto nei post sopra ...

Hai provato sudo git push -u origin --all ? A volte è l'unica cosa di cui hai bisogno per evitare questo problema. Ti chiede la password del sistema di amministrazione - quella che puoi fare per accedere al tuo computer - ed è quello che devi spingere - o commettere, se è il caso.