Fehler beim Pushing an GitHub - unzureichende Berechtigung zum Hinzufügen eines Objekts zur Repository-Datenbank

Ich erhalte einen ungewöhnlichen Fehler, während ich versuche, einen "Git-Push" für mein GitHub-Repository durchzuführen:

Objekte zählen: 8, fertig.
Delta-Komprimierung mit 2 Threads.
Objekte komprimieren: 100% (4/4), fertig.
Objekte schreiben: 100% (5/5), 1,37 KiB, fertig.
Insgesamt 5 (Delta 2), wiederverwendet 0 (Delta 0)
Fehler: Unzureichende Berechtigung zum Hinzufügen eines Objekts zur Repository-Datenbank ./Objekte

fatal: Objekt konnte nicht geschrieben werden
Fehler: Entpack-Objekte mit Fehlercode 128 beendet
Fehler: Entpacken fehlgeschlagen: Entpack-Objekte abnormaler Exit
An git@github.com: bixo / bixo.git
 ! [Remote abgelehnt] Master -> Master (n / a (Entpackerfehler))
Fehler: Einige Refs konnten nicht an 'git@github.com: bixo / bixo.git' gesendet werden.

• Nach einem sauberen Klon von GitHub kann ich eine geänderte Datei bearbeiten / hinzufügen / festschreiben / pushen.
• Wenn ich dies dann ein zweites Mal wiederhole, erhalte ich den obigen Fehler.
• Ich kann ganz gut auf andere GitHub-Repositories pushen.
• Ich habe die Datei- / Verzeichnisberechtigungen auf meiner Seite überprüft und sie scheinen in Ordnung zu sein.
• Ich verwende Git 1.6.2.3 unter Mac OS X 10.5.8

Das obige Repository war die Quelle meines Spaßes für eine frühere Stack Overflow-Frage ( SO 1904860 ), sodass das GitHub-Repo möglicherweise beschädigt wurde. Das einzige Problem , das ich über ähnliche Suche gefunden habe , war ein auspacken failed Problem auf Github berichtet. Ist schon jemand auf dieses Problem gestoßen, insbesondere wenn GitHub nicht verwendet wird?

Wenn Sie diesen Fehler außerhalb von Github sehen, finden Sie hier eine Abhilfe.

Erhalten Sie dies von: 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

Danach sollte der Git-Daemon beim Schreiben in .git / Objekte die Gruppendateiberechtigungen verwenden.

Normalerweise wird dieses Problem durch falsche Benutzer- und Gruppenberechtigungen auf dem Dateisystem Ihres Git-Servers verursacht. Das Git-Repository muss dem Benutzer und auch seiner Gruppe gehören.

Beispiel:

Wenn Ihr Benutzer "git" heißt, ist seine Gruppe "gitgroup" und der Speicherort des Git-Repos: git@mygitserverxyz.com: path / to / repo.git

dann mache ein:

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

Dies hat den Fehler mit der unzureichenden Berechtigung für mich behoben.

sudo chmod 777 -R .git/objects

Das ist mir passiert, als ich es versucht habe git pull. Einige Analysen zeigten, dass sich jemand in der Vergangenheit mit root befasst hatte, wodurch einige Objekte mit root-Besitz erstellt wurden .git/objects.

Also rannte ich

cd <repo>
la .git/objects/

und das zeigte rootBesitz für einige Objekte (Verzeichnisse) wie folgt:

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

Dann rannte ich

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

und es hat funktioniert!

Ich habe natürlich den Benutzer durch meinen echten Benutzer ersetzt.

Nichts von alledem hat bei mir funktioniert. Ein paar Stunden später fand ich den Grund für das Problem: Ich verwendete eine Repo-URL des Typs

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

Leider habe ich eine Kitt-Sitzung mit dem Namen gespeichert, der für example.comdie Anmeldung als Benutzer konfiguriert wurde myOtherUser.

Während ich dachte, dass git example.commit dem Benutzer 'git' eine Verbindung zum Host herstellt , hat Git / TortoiseGit eine Verbindung zu der Kitt-Sitzung hergestellt, example.comdie den Benutzer verwendet myOtherUser. Dies führt zu genau demselben ..insufficient permission..Fehler (da sich beide Benutzer in unterschiedlichen Gruppen befinden).

Lösung: Benennen Sie die Kitt-Sitzung example.comin ummyOtherUse@example.com

chmod sollte chown sein, also ist die richtige Zeile:

sudo chown -R gituser:gituser objects

Seltsamerweise hatte ich dieses Problem bei einem Klon meines Repos, aber nicht bei einem anderen. Abgesehen vom erneuten Klonen des Repos (was ein Mitarbeiter getan hat, um dieses Problem erfolgreich zu umgehen), gelang es mir, einen "Git-Reset" für das Commit durchzuführen, das ich vor Beginn der Fehler hatte. Dann habe ich die Änderungen erneut festgeschrieben und konnte danach erfolgreich pushen. Trotz aller Anzeichen gab es ein Problem auf dem Server, in diesem Fall war es anscheinend ein Hinweis auf eine Kuriosität im lokalen Repo.

Ich habe diesen Fehler erhalten, weil jedes Mal, wenn ein Benutzer Inhalte pusht, die Gruppe der Datei in den Benutzer geändert wurde. Wenn dann ein anderer Benutzer versuchte, in das Repository zu pushen, verursachte dies einen Berechtigungsfehler und der Push wurde abgelehnt. Sie müssen also Ihren Systemadministrator bitten, die Einstellungen des Repositorys zu ändern, damit die Gruppe einer Datei im Repository für keinen Push durch einen Benutzer geändert wird.

Um ein solches Problem zu vermeiden, stellen Sie bitte sicher, dass Sie beim Initialisieren Ihres Git-Repositorys den Befehl "git init --shared = group" verwenden.

Wenn dieser Fehler später nach dem Festlegen der Berechtigungen weiterhin auftritt, müssen Sie möglicherweise Ihre Erstellungsmaske ändern. Wir haben festgestellt, dass unsere neuen Commits (Ordner unter Objekten) immer noch ohne Gruppenschreibberechtigung erstellt wurden, sodass nur die Person, die sie festgeschrieben hat, in das Repository pushen konnte.

Wir haben dies behoben, indem wir die Umask der SSH-Benutzer auf 002 mit einer geeigneten Gruppe gesetzt haben, die von allen Benutzern gemeinsam genutzt wird.

z.B

umask 002

Dabei erlaubt die mittlere 0 standardmäßig das Schreiben von Gruppen.

Nachdem Sie einige Dinge hinzugefügt haben ... legen Sie sie fest und schieben Sie sie schließlich! KNALL!! Starten Sie alle Probleme ... Wie Sie beachten sollten, gibt es einige Unterschiede in der Art und Weise, wie neue und vorhandene Projekte definiert wurden. Wenn eine andere Person versucht, dieselben Dateien oder Inhalte hinzuzufügen / festzuschreiben / zu pushen (git behält beide als dieselben Objekte bei), tritt der folgende Fehler auf:

$ 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

Um dieses Problem zu lösen, müssen Sie das Berechtigungssystem des Betriebssystems berücksichtigen, da Sie in diesem Fall dadurch eingeschränkt sind. Um das Problem besser zu verstehen, überprüfen Sie den Ordner Ihres Git-Objekts (.git / Objekte). Sie werden wahrscheinlich so etwas sehen:

<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

* Beachten Sie, dass die Berechtigungen dieser Datei nur für Ihre Benutzer erteilt wurden. Niemand wird sie niemals ändern können ... *

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

LÖSUNG DES PROBLEMS

Wenn Sie über eine Superuser-Berechtigung verfügen, können Sie alle Berechtigungen mithilfe von Schritt 2 selbst ändern. In jedem anderen Fall müssen Sie alle Benutzer mit Objekten, die mit ihren Benutzern erstellt wurden, fragen. Verwenden Sie den folgenden Befehl, um zu erfahren, wer sie sind ::

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

Jetzt müssen Sie und alle Benutzer des Dateibesitzers die Berechtigung für diese Dateien ändern.

$ chmod -R 774 .

Danach müssen Sie eine neue Eigenschaft hinzufügen, die --shared = group entspricht, die für das neue Repository erstellt wurde. Gemäß der Dokumentation wird das Repository für die Gruppe beschreibbar. Führen Sie Folgendes aus:

$ git config core.sharedRepository group

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

Versuchen Sie Folgendes zu tun:

Gehen Sie zu Ihrem Server

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

Gehen Sie dann zu Ihrer Arbeitskopie (lokales Repository) und packen Sie sie um git repack master

Funktioniert perfekt für mich.

Sie können dies verwenden

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

sudo su root

chown -R user:group dir

Das dir ist dein Git Repo.

Dann mach:

git pull origin master

Sie werden Änderungen an Commits anderer sehen.

 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 - es stellte sich heraus, dass es sich um ein Berechtigungsproblem auf GitHub handelte, das während der Verzweigung von emi / bixo zu bixo / bixo aufgetreten ist. Sobald Tekkub diese behoben hatte, funktionierte es wieder.

Da sich der Fehler auf Berechtigungen für den Objektordner bezieht, habe ich einen Chown direkt für den Objektordner durchgeführt und es hat bei mir funktioniert.

Das funktioniert:

sudo chmod -R gituser.gituser objects

Ich denke, viele wie ich landen in solchen Foren, wenn das oben beschriebene Git-Problem auftritt. Es gibt jedoch so viele Ursachen, die zu dem Problem führen können, dass ich nur mitteilen möchte, was meine Probleme verursacht hat, damit andere lernen können, wie ich bereits von oben gelernt habe.

Ich habe meine Repos auf einem Linux-NAS von sitecom (Kaufen Sie niemals NAS von Sitecom, pleeaaase). Ich habe hier ein Repo, das auf vielen Computern geklont ist, auf das ich aber plötzlich keinen Push mehr hatte. Kürzlich habe ich ein Plugin installiert, damit mein NAS als Squeezebox-Server fungieren kann.

Dieser Server sucht nach Medien, die freigegeben werden sollen. Was ich nicht wusste, war, dass der Server aufgrund eines Fehlers die Benutzer- und Gruppeneinstellung so ändert, dass sie "Squeeze: User" für alle Dateien enthält, in die er schaut. Und das sind ALLE Dateien. So änderte ich die Rechte, die ich pushen musste.

Der Server ist weg und die richtigen Rechteeinstellungen werden wiederhergestellt und alles funktioniert einwandfrei.

ich benutzte

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

Wo Myuser und Mygroup vom Kurs abweichen müssen, müssen die richtigen Einstellungen für Ihr System vorgenommen werden. versuche git: git oder gituser: gituser oder etwas anderes, das dir gefallen könnte.,

Überprüfen Sie das 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)

Beachten Sie, dass es hier einen 'git @' - Teilstring gibt, der git anweist, sich auf dem Remote-Server als Benutzername 'git' zu authentifizieren. Wenn Sie diese Zeile weglassen, wird git unter einem anderen Benutzernamen authentifiziert, daher tritt dieser Fehler auf.

In meinem Fall gab es keine einheitliche Authentifizierung (z. B. innerhalb der Domäne + AD-ähnlicher Dienst) zwischen meinem Computer und dem virtuellen Git-Server. Daher sind Git-Benutzer und -Gruppen für den virtuellen Server lokal. In meinem Fall wurde mein Remote-Benutzer (mit dem ich mich beim Remote-Server anmelde) einfach nicht zur Remote-Git-Gruppe hinzugefügt.

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

Überprüfen Sie anschließend die Berechtigungen, wie in den obigen Beiträgen beschrieben ...

Haben Sie versucht, sudo git push -u origin --all ? Manchmal ist es das einzige, was Sie brauchen, um dieses Problem zu vermeiden. Sie werden nach dem Kennwort des Administratorsystems gefragt - das Kennwort, mit dem Sie sich bei Ihrem Computer anmelden können - und das müssen Sie pushen - oder festschreiben, wenn dies der Fall ist.