Git verweigert seit 2.35.2 die Arbeit, wenn der Repository-Ordner einem anderen Benutzer gehört. Das ist kein Bug, sondern ein Sicherheitsriegel.
Aufwand:
ca. 10 Min.
Gilt für:
Git ab Version 2.35.2
Das Symptom
Ein Git-Befehl, der gestern noch lief, bricht heute sofort ab:
fatal: detected dubious ownership in repository at '/pfad/zum/repo'
Kein Commit, kein Status, kein Pull – Git tut gar nichts mehr, und der vorgeschlagene
Ausweg in der Meldung ist ausgerechnet der Befehl, den man nicht blind kopieren sollte.
Die „Layer 8“-Wahrheit
Das ist kein Fehler, sondern eine Sicherheitsmaßnahme, die absichtlich im Weg steht.
Sie kam mit Git 2.35.2 als Antwort auf eine Schwachstelle (CVE-2022-24765): Auf einem
Rechner mit mehreren Benutzern konnte ein Angreifer in einem Ordner ein .git-Verzeichnis
mit bösartiger Konfiguration ablegen; wer dort zufällig einen Git-Befehl absetzte, führte
fremde Anweisungen mit den eigenen Rechten aus. Seither weigert sich Git, in einem
Arbeitsverzeichnis zu arbeiten, das jemand anderem gehört als der Person, die den Befehl
tippt.
Der entscheidende Punkt steht selten in den Kommentaren unter der Fehlermeldung: In den
allermeisten Fällen ist der Besitz das eigentliche Problem, nicht die Warnung. Wer sein
Repository einmal versehentlich mit sudo git clone geholt hat, besitzt anschließend
einen Ordner, der root gehört – und arbeitet danach als normaler Benutzer dagegen an. Die
ehrliche Lösung ist dann nicht, Git das Meckern abzugewöhnen, sondern den Besitz
zurückzuholen. Erst wenn der fremde Besitz wirklich gewollt ist – im CI-Container, auf
einer gemeinsam genutzten Freigabe –, ist safe.directory das richtige Werkzeug. Und dann
für genau diesen einen Pfad, nicht für alle auf einmal. Der Stern ist bequem und
verschenkt genau den Schutz, dessentwegen die Meldung existiert.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Verstehen, warum Git blockiert
Git prüft seit Version 2.35.2, ob der Ordner mit dem .git-Verzeichnis demselben Benutzer gehört, der den Befehl absetzt. Gehört er einem anderen – etwa root oder einem früheren Konto –, bricht Git ab, statt fremde Konfiguration auszuführen. Der Riegel schließt eine echte Rechteausweitung: In einem fremden Repository könnten Hooks oder Pfad-Einstellungen stehen, die man nicht selbst geschrieben hat.
2.
Den Besitzer tatsächlich prüfen
Erst nachsehen, wem der Ordner gehört – oft ist das die eigentliche Diagnose. Steht dort root, obwohl du als normaler Benutzer arbeitest, wurde das Repository vermutlich einmal mit sudo geklont. Das ist die Ursache, nicht die Meldung.
ls -ld /pfad/zum/repo
3.
Wenn möglich, den Besitz geradeziehen
Die saubere Lösung ist nicht, den Riegel zu umgehen, sondern den falschen Besitz zu beheben. Gehört dir das Repository ohnehin, gib es dir zurück – dann verschwindet die Meldung, weil ihr Grund verschwindet.
sudo chown -R $USER /pfad/zum/repo
4.
Nur wenn der fremde Besitz gewollt ist: als sicher eintragen
Manchmal muss der Ordner einem anderen Konto gehören, etwa in einem CI-Container oder auf einem gemeinsamen Laufwerk. Dann – und nur dann – trägt man genau diesen Pfad als vertrauenswürdig ein. Das ist eine bewusste Ausnahme für einen konkreten Ort, kein Generalschlüssel.
Es gibt die Sammel-Ausnahme mit einem Sternchen, die jeden Ordner als sicher erklärt. Sie schaltet genau die Prüfung ab, die hier gerade etwas gemeldet hat. In einem kurzlebigen, isolierten Container ist das vertretbar; auf einem Rechner, an dem mehrere Menschen arbeiten, gibt man damit den Schutz auf, für den es die Meldung überhaupt gibt.
git config --global --add safe.directory '*'
Häufige Fragen (FAQ)
?Ist mein Repository beschädigt oder gehackt?
Nein. Die Meldung sagt nichts über den Inhalt des Repositorys aus, sondern nur über den Besitzer des Ordners. In aller Regel ist der Auslöser harmlos: Der Ordner wurde einmal mit sudo angelegt oder liegt auf einem Datenträger, der von einem anderen System stammt. Git ist hier nur vorsichtig, nicht alarmiert.
?Soll ich safe.directory einfach auf den Stern setzen?
Nur mit Bedacht. Der Stern erklärt jeden Ordner pauschal für sicher und deaktiviert damit die Prüfung vollständig. In einem Wegwerf-Container ist das oft in Ordnung. Auf einem geteilten oder dauerhaften System ist der bessere Weg, entweder den Besitz zu korrigieren oder nur den einen betroffenen Pfad einzutragen – so bleibt der Schutz für alle anderen Ordner erhalten.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der Diff markiert jede Zeile als geändert, obwohl nur ein Wort angepasst wurde? Zeilenenden. Windows und Unix streiten sich um ein unsichtbares Zeichen.
Git meldet „detached HEAD“? Du stehst nicht auf einem Branch, sondern direkt auf einem Commit — Änderungen hier gehen ohne Gegenmaßnahme leicht verloren.
git commit bricht mit „gpg failed to sign the data“ ab? Meist fehlt der passende Schlüssel, oder GPG kann im Terminal nicht nach der Passphrase fragen.