Errore Git: impossibile aggiungere a .git / logs / refs / remotes / origin / master: autorizzazione negata

87

Sto riscontrando uno strano problema che non riesco a risolvere. Ecco cosa è successo:

Avevo alcuni file di registro in un repository GitHub che non volevo lì. Ho trovato questo script che rimuove completamente i file dalla cronologia di git in questo modo:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Ovviamente prima ho fatto un backup e poi l'ho provato. Sembrava funzionare bene. Ho quindi eseguito un git push -f e sono stato accolto con i seguenti messaggi:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Tutto sembra essere andato bene, però, perché i file sembrano essere spariti dal repository GitHub, se provo a premere di nuovo ottengo la stessa cosa:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

MODIFICARE

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Grazie!

MODIFICARE

Uh Oh. Problema. Ho lavorato a questo progetto tutta la notte e sono andato a mettere le mie modifiche:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Così io:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

Provo di nuovo il commit e ottengo:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Così io:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

E poi provo di nuovo il commit:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To git@github.com:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Evviva. Salto su http://GitHub.com e controllo il repository, e il mio ultimo commit non è da nessuna parte. :: scratch head :: Quindi spingo di nuovo:

Everything up-to-date

Umm ... non sembra. Non ho mai avuto questo problema prima, potrebbe essere un problema con GitHub? o ho sbagliato qualcosa con il mio progetto git?

MODIFICARE

Non importa, ho fatto un semplice:

git push origin master

e ha spinto bene.

git  github 
— Corbin Tarrant
fonte

Risposte:

219

Sembra che tu abbia eseguito git come root localmente, cambiando così la proprietà su alcuni dei file che tracciano la posizione del originramo.

Correggi la proprietà del file e dovresti stare bene:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .
— Charles Duffy
fonte
1
Quel comando ha funzionato per me. L'ho eseguito dalla radice del clone. Grazie @CharlesDuffy!
— ariestav
4
@ Mr.Stranger, solo se hai un valore IFS e un nome utente sani (i nomi utente con spazi possono essere presenti, ad esempio su cygwin). È più sicuro citare: sudo chown -R "$USER" .e non assumere la sanità mentale. :)
— Charles Duffy
@ Mr.Stranger, ... inoltre, USERnon è garantito da pubs.opengroup.org/onlinepubs/009695399/utilities/… , quindi potrebbe essere più sicuro da usare "$(id -un)".
— Charles Duffy,
Dice il mio utente is not in the sudoers file. This incident will be reported.: qualche consiglio su cosa posso fare? Grazie.
— giovannipds
1
La sintassi precedente è l' espansione dei parametri ; "${var:-default}"si espande al valore della variabile "$var", a meno che quel valore non sia vuoto o non impostato, nel qual caso si risolve in default. Quindi, espandiamo "$USER"o l'output generato eseguendo id -un.
— Charles Duffy
4

Concentriamoci su ciò di cui si lamenta esattamente:

Errore di autorizzazione negata: impossibile aggiornare il riferimento "refs / remotes / origin / master".

Prima di apportare modifiche ricorsive a mod / proprietà, raggiungi quel file e correggi eventuali autorizzazioni errate.

Penso di aver causato questo problema creando un ramo mentre ero root e poi provando a fare confusione con quel ramo come mio utente.

— Andrew E
fonte
3
Correggere i file di proprietà di chiunque non sia l'utente previsto che possieda l'intero albero dei sorgenti uno per uno è davvero un miglioramento?
— Charles Duffy
2

Nel mio caso ho creato i file con i permessi di root localmente e ho provato a spingere il codice in remoto con i permessi locali. Quindi ho eseguito questo comando

$find . -user root

per scoprire cosa hanno tutti i file "root" come proprietario. E poi ho cambiato proprietario per tutti i file che si trovano sotto root in locale usando il seguente comando

$sudo chown parineethat `find . -user root`

Quindi sono stato in grado di spingere il mio codice da locale a remoto.

— Parineetha
fonte
sudo chown parineethat `find . -user root` è inaffidabile - non funzionerà correttamente con nomi di file con spazi. Invece, sudo find . -user root -exec chown parineethat {} +. Vedi BashPitfalls # 1 per discussioni pertinenti.
— Charles Duffy,
1

Questo cambierà tutti i tuoi file e directory .git in modo ricorsivo (da root a 1000) e ti darà un elenco completo di tutte le modifiche apportate nel terminale.

sudo chown -Rc $ UID .git /

— Donald L Wilson
fonte
0

Ho provato a correggere la proprietà per Git, ma ancora non funziona.

Ma sono riuscito a risolverlo creando il ramo locale con un nome diverso ed eliminandolo.

Quindi, controllo di nuovo lo stesso nome del ramo e funziona.

TLDR;

Non riesco a controllare "staging / rc".

Quindi, eseguo il checkout usando staginginvece che il telecomando punta a "staging / rc".

E lo elimino e faccio di nuovo il checkout. Ma questa volta uso staging/rccome nome della mia filiale locale.

Funziona e non ho idea del perché.

— Morgan Koh
fonte
-16

Per prima cosa, dai le autorizzazioni rootdall'account come di seguito

chmod -R 777 foldername

dopo di che eseguire il comando commit

— Viru
fonte
7
Questo è estremamente pericoloso: fornisce a qualsiasi account sul sistema, incluso un demone compromesso con privilegi di "nessuno", l'accesso in scrittura ai file. I daemon di sistema usano "nessuno" (o altri account non privilegiati) per i componenti sensibili alla sicurezza perché l'account nessuno non dovrebbe essere in grado di fare qualcosa di troppo rischioso anche se è compromesso. Consentendo a tutti gli utenti, anche a nessuno, l'accesso in scrittura ai tuoi file, stai rendendo inutili le misure di sicurezza essenziali.
— Charles Duffy
1
Se per qualche motivo volevi che i tuoi file fossero di proprietà di root e scrivibili da uno specifico utente non root, il modo sicuro per farlo (su un sistema in cui ogni utente ha il proprio gruppo, come è prassi standard) è chown -R root:user directory, e quindi chmod -R 775 directory(o 770, se anche altri account non necessitano dell'accesso in lettura).
— Charles Duffy
1
@JasonGlisson, qualcosa che "funziona" solo creando enormi buchi di sicurezza è probabilmente qualcosa che sarebbe meglio rimanere rotto.
— Charles Duffy
1
@JasonGlisson, dal momento che forniamo consulenza sia come che a una comunità, come membro di quella comunità, il tipo e la qualità dei consigli che forniamo sono affari miei tanto quanto quelli di chiunque altro e, come qualcuno che lavora nella sicurezza , Sono ben posizionato per commentare l'argomento. Vedi commento iniziale, re: impact.
— Charles Duffy
1
@ JasonGlisson, ... per quanto riguarda il motivo per cui il mio consiglio non ha funzionato per te, avrei bisogno di vedere i dettagli: un registro dei comandi eseguiti, in ordine, con un prompt che mostra la directory di lavoro corrente prima di ciascuno; testo di eventuali errori emessi; ecc - per commentare; ma il luogo per quella discussione sarebbe allegato alla risposta per la quale stai segnalando risultati negativi, al contrario di qui.
— Charles Duffy
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.