Git-Fehler: An .git / logs / refs / remotes / origin / master kann nicht angehängt werden: Berechtigung verweigert


84

Ich habe ein seltsames Problem, das ich scheinbar nicht lösen kann. Folgendes ist passiert:

Ich hatte einige Protokolldateien in einem Github-Repository, die ich dort nicht wollte. Ich habe dieses Skript gefunden, das Dateien wie folgt vollständig aus dem Git-Verlauf entfernt:

    #!/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

Ich habe natürlich zuerst ein Backup erstellt und es dann versucht. Es schien gut zu funktionieren. Ich habe dann einen Git Push -f gemacht und wurde mit folgenden Meldungen begrüßt:

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

Alles scheint gut gelaufen zu sein, da die Dateien aus dem GitHub-Repository verschwunden zu sein scheinen. Wenn ich versuche, es erneut zu pushen, erhalte ich dasselbe:

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

BEARBEITEN

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

Vielen Dank!

BEARBEITEN

Oh oh. Problem. Ich habe die ganze Nacht an diesem Projekt gearbeitet und bin nur gegangen, um meine Änderungen zu übernehmen:

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

Also ich:

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

Ich versuche das Commit erneut und bekomme:

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

Also ich:

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

Und dann versuche ich es noch einmal:

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

Hurra. Ich springe auf http://GitHub.com und überprüfe das Repository. Mein letztes Commit ist nicht zu finden. :: Kratzkopf :: Also drücke ich nochmal:

Everything up-to-date

Ähm ... es sieht nicht so aus. Ich hatte dieses Problem noch nie zuvor. Könnte dies ein Problem mit Github sein? oder habe ich etwas mit meinem Git-Projekt durcheinander gebracht?

BEARBEITEN

Egal, ich habe ein einfaches gemacht:

git push origin master

und es drückte gut.

Antworten:


215

Es sieht so aus, als hätten Sie git lokal als root ausgeführt und damit den Besitz einiger Dateien geändert, die den Speicherort des originZweigs verfolgen .

Korrigieren Sie den Dateibesitz, und es sollte Ihnen gut gehen:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .

1
Dieser Befehl hat bei mir funktioniert. Ich habe es von der Wurzel des Klons aus ausgeführt. Danke @CharlesDuffy!
Ariestav

4
@ Mr.Stranger, nur wenn Sie einen vernünftigen IFS-Wert und Benutzernamen haben (Benutzernamen mit Leerzeichen können beispielsweise auf cygwin vorkommen). Sicherer zu zitieren: sudo chown -R "$USER" .und nicht von Vernunft ausgehen. :)
Charles Duffy

@ Mr.Stranger, ... wird auch USERnicht von pubs.opengroup.org/onlinepubs/009695399/utilities/… garantiert , daher ist die Verwendung möglicherweise sicherer "$(id -un)".
Charles Duffy

Es sagt mein Benutzer is not in the sudoers file. This incident will be reported.- irgendeinen Tipp darüber, was ich tun kann? Vielen Dank.
Giovannipds

1
Die obige Syntax lautet Parametererweiterung . "${var:-default}"wird auf den Wert der Variablen erweitert "$var", es sei denn, dieser Wert ist leer oder nicht festgelegt. In diesem Fall wird er in aufgelöst default. Daher erweitern wir entweder auf "$USER"oder die Ausgabe wird durch Ausführen generiert id -un.
Charles Duffy

3

Konzentrieren wir uns auf das, worüber es sich genau beschwert:

Fehler "Berechtigung verweigert": Die Referenz "refs / remotes / origin / master" kann nicht aktualisiert werden.

Bevor Sie rekursive Änderungen an Modifikationen / Besitzern vornehmen, gehen Sie den Weg zu dieser Datei und korrigieren Sie alle falschen Berechtigungen.

Ich glaube, ich habe dieses Problem verursacht, indem ich einen Zweig erstellt habe, während ich root war, und dann versucht habe, diesen Zweig als meinen Benutzer zu verwenden.


3
Ist es wirklich eine Verbesserung, die Dateien zu reparieren, deren Eigentümer nicht der Benutzer ist, von dem erwartet wird, dass er den gesamten Quellbaum einzeln besitzt?
Charles Duffy

2

In meinem Fall habe ich die Dateien mit Root-Berechtigung lokal erstellt und versucht, den Code mit lokalen Berechtigungen auf Remote zu übertragen. Also habe ich diesen Befehl ausgeführt

$find . -user root

um herauszufinden, was alle Dateien "root" als Eigentümer haben. Und dann habe ich mit dem folgenden Befehl den Besitzer für alle Dateien, die sich unter root befinden, in local geändert

$sudo chown parineethat `find . -user root`

Dann konnte ich meinen Code von lokal auf remote verschieben.


sudo chown parineethat `find . -user root` ist unzuverlässig - funktioniert nicht richtig mit Dateinamen mit Leerzeichen. Stattdessen sudo find . -user root -exec chown parineethat {} +. Siehe BashPitfalls # 1 für relevante Diskussionen.
Charles Duffy

1

Dadurch werden alle Ihre .git-Dateien und -Verzeichnisse rekursiv geändert (von root auf 1000) und Sie erhalten eine vollständige Liste aller im Terminal vorgenommenen Änderungen.

sudo chown -Rc $ UID .git /


0

Ich habe versucht, den Besitz für Git zu reparieren, aber es funktioniert immer noch nicht.

Ich habe es jedoch geschafft, das Problem zu beheben, indem ich den lokalen Zweig mit einem anderen Namen erstellt und gelöscht habe.

Dann überprüfe ich noch einmal den gleichen Filialnamen und es funktioniert.

TLDR;

Ich kann `staging / rc 'nicht auschecken.

Also checke ich stagingstattdessen mit aus, dass die Fernbedienung auf "staging / rc" zeigt.

Und ich lösche es und checke wieder aus. Diesmal verwende ich jedoch staging/rcmeinen lokalen Filialnamen.

Es funktioniert und ich habe keine Ahnung warum.


-16

Bitte geben Sie zuerst die Berechtigungen von rootKonto wie unten

chmod -R 777 foldername

Führen Sie danach den Befehl commit aus


7
Dies ist äußerst gefährlich - es gibt jedem Konto auf dem System, einschließlich eines kompromittierten Daemons mit nur "niemandem" -Rechten, Schreibzugriff auf Ihre Dateien. System-Daemons verwenden "Nobody" (oder andere nicht privilegierte Konten) für sicherheitsrelevante Komponenten, da das Nobody-Konto selbst dann nicht zu riskant sein soll, wenn es kompromittiert wird. Indem Sie allen Benutzern, auch niemandem, Schreibzugriff auf Ihre Dateien gewähren, machen Sie wichtige Sicherheitsmaßnahmen nutzlos.
Charles Duffy

1
Wenn Sie aus irgendeinem Grund möchten, dass Ihre Dateien Root gehören und von einem bestimmten Nicht-Root-Benutzer beschreibbar sind, können Sie dies auf einem System, auf dem jeder Benutzer seine eigene Gruppe hat, wie es in der Standardpraxis üblich ist chown -R root:user directory, und dann chmod -R 775 directory(oder 770, wenn andere Konten auch keinen Lesezugriff benötigen).
Charles Duffy

1
@JasonGlisson, etwas, das nur "funktioniert", indem es massive Sicherheitslücken schafft, ist wahrscheinlich etwas, das besser dran wäre, kaputt zu bleiben.
Charles Duffy

1
@JasonGlisson, insofern wir als Mitglied einer Community als auch für eine Community Ratschläge erteilen, ist die Art und Qualität der Beratung, die wir anbieten, meine Sache genauso wie die anderer - und als jemand, der im Bereich Sicherheit arbeitet Ich bin gut aufgestellt, um das Thema zu kommentieren. Siehe ersten Kommentar zu: Auswirkungen.
Charles Duffy

1
@JasonGlisson, ... warum mein Rat bei Ihnen nicht funktioniert hat, muss ich Details anzeigen - ein Protokoll der Befehle, das der Reihe nach ausgeführt wird, mit einer Eingabeaufforderung, die vor jedem das aktuelle Arbeitsverzeichnis anzeigt; Text etwaiger Fehler; etc - um zu kommentieren; Der Platz für diese Diskussion hängt jedoch von der Antwort ab, für die Sie im Gegensatz zu hier schlechte Ergebnisse melden.
Charles Duffy
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.