Erreur lors du transfert vers GitHub - autorisation insuffisante pour ajouter un objet à la base de données du référentiel

Je reçois une erreur inhabituelle en essayant de faire un "git push" dans mon dépôt GitHub:

Comptage des objets: 8, terminé.
Compression delta en utilisant 2 threads.
Compression d'objets: 100% (4/4), terminé.
Écriture d'objets: 100% (5/5), 1,37 Kio, terminé.
Total 5 (delta 2), réutilisé 0 (delta 0)
erreur: autorisation insuffisante pour ajouter un objet à la base de données du référentiel ./objects

fatal: échec d'écriture de l'objet
erreur: décompresser les objets sortis avec le code d'erreur 128
erreur: échec du déballage: sortie anormale des objets décompressés
À git@github.com: bixo / bixo.git
 ! [distant rejeté] maître -> maître (n / a (erreur de décompresseur))
erreur: échec de l'envoi de certaines références à 'git@github.com: bixo / bixo.git'

• Après un clone propre à partir de GitHub, je peux éditer / ajouter / valider / pousser un fichier modifié.
• Si je le répète une deuxième fois, j'obtiens l'erreur ci-dessus.
• Je peux très bien pousser vers d'autres référentiels GitHub.
• J'ai vérifié les autorisations de fichiers / répertoires de mon côté, et elles semblent OK.
• J'exécute git 1.6.2.3 sur Mac OS X 10.5.8

Le dépôt ci-dessus a été la source de mon plaisir pour une question précédente de Stack Overflow ( SO 1904860 ), alors peut-être que le dépôt GitHub a été corrompu. Le seul problème similaire que j'ai trouvé lors de la recherche était un problème d' échec de décompression signalé sur github. Quelqu'un d'autre a-t-il déjà rencontré ce problème, en particulier lorsqu'il n'utilise pas GitHub?

Lorsque vous voyez cette erreur en dehors de github, voici un remède.

Obtenu ceci de: 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

Après cela, le démon git doit utiliser les autorisations de fichier de groupe lors de l'écriture dans .git / objects.

Ce problème est généralement causé par des autorisations utilisateur et de groupe incorrectes sur le système de fichiers de vos serveurs Git. Le référentiel git doit appartenir à l'utilisateur ainsi qu'à son groupe.

Exemple:

Si votre utilisateur s'appelle "git", son groupe "gitgroup" et l'emplacement du dépôt Git est: git@mygitserverxyz.com: chemin / vers / repo.git

puis faites un:

sudo chown -R git: chemin gitgroup / vers / repo.git /

Cela a corrigé l'erreur d'autorisation insuffisante git pour moi.

sudo chmod 777 -R .git/objects

Cela m'est arrivé quand j'ai essayé git pull. Certaines analyses ont montré que quelqu'un s'était engagé avec root dans le passé, créant ainsi des objets avec la propriété root .git/objects.

Alors j'ai couru

cd <repo>
la .git/objects/

et qui a montré la rootpropriété de certains objets (répertoires) comme celui-ci:

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

Puis j'ai couru

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

et ça a marché!

Je remplaçais l' utilisateur par mon utilisateur réel, bien sûr.

Rien de ce qui précède n'a fonctionné pour moi. Quelques heures plus tard, j'ai trouvé la raison du problème: j'ai utilisé une URL de dépôt du type

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

Malheureusement, j'ai stocké une session putty avec le nom example.comqui a été configuré pour se connecter en tant qu'utilisateur myOtherUser.

Donc, alors que je pensais que git se connecte à l'hôte example.comavec l'utilisateur 'git', Git / TortoiseGit s'est connecté à la session putty example.comqui utilise l'utilisateur myOtherUser. Cela conduit exactement à la même ..insufficient permission..erreur (car les deux utilisateurs sont dans des groupes différents).

Solution: renommez la session de mastic example.comenmyOtherUse@example.com

chmod doit être chown, donc la ligne correcte est:

sudo chown -R gituser:gituser objects

Curieusement, j'ai eu ce problème sur un clone du repo que j'avais, mais pas sur un autre que j'avais. En plus du re-clonage du dépôt (ce qu'un collègue a fait pour contourner ce problème), j'ai réussi à faire une "réinitialisation git" du commit que j'avais avant le début des échecs. Ensuite, j'ai réengagé les changements, et j'ai pu pousser avec succès après cela. Donc, malgré toutes les indications, il y avait un problème sur le serveur, dans ce cas, cela indiquait apparemment une certaine bizarrerie dans le repo local.

J'obtenais cette erreur parce que chaque fois qu'un utilisateur envoie du contenu, le groupe du fichier est changé pour l'utilisateur. Et puis si un autre utilisateur essayait de pousser dans le référentiel, cela provoquait une erreur d'autorisation et le push était rejeté. Il faut donc demander à votre administrateur système de modifier les paramètres du référentiel afin que le groupe de n'importe quel fichier dans le référentiel ne soit pas modifié pour une poussée par un utilisateur.

Pour éviter un tel problème, veuillez vous assurer que lorsque vous initialisez votre dépôt git, utilisez la commande "git init --shared = group".

Si vous obtenez toujours cette erreur plus tard après avoir défini les autorisations, vous devrez peut-être modifier votre masque de création. Nous avons constaté que nos nouveaux commits (dossiers sous objets) étaient toujours en cours de création sans autorisation d'écriture de groupe, donc seule la personne qui les a validés pouvait pousser dans le référentiel.

Nous avons résolu ce problème en définissant le umask des utilisateurs SSH sur 002 avec un groupe approprié partagé par tous les utilisateurs.

par exemple

umask 002

où le 0 du milieu autorise l'écriture de groupe par défaut.

Après avoir ajouté des trucs ... engagez-les et après tout fini, poussez-les! COUP!! Commencez tous les problèmes ... Comme vous devriez le remarquer, il existe des différences dans la façon dont les projets nouveaux et existants ont été définis. Si une autre personne essaie d'ajouter / valider / pousser les mêmes fichiers, ou contenu (git garde les deux comme les mêmes objets), nous serons confrontés à l'erreur suivante:

$ 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

Pour résoudre ce problème, vous devez avoir quelque chose à l'esprit du système d'autorisations du système opérationnel car vous êtes limité par celui-ci dans ce cas. Pour mieux comprendre le problème, allez-y et vérifiez le dossier de votre objet git (.git / objets). Vous verrez probablement quelque chose comme ça:

<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

* Notez que les permissions de ces fichiers n'ont été accordées que pour vos utilisateurs, personne ne pourra jamais les changer ... *

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

RÉSOUDRE LE PROBLÈME

Si vous disposez d'une autorisation de super utilisateur, vous pouvez continuer et modifier toutes les autorisations par vous-même en utilisant l'étape deux, dans tous les autres cas, vous devrez demander à tous les utilisateurs avec des objets créés avec leurs utilisateurs, utilisez la commande suivante pour savoir qui ils sont :

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

Maintenant, vous et tous les utilisateurs propriétaires du fichier devrez modifier l'autorisation de ces fichiers, en faisant:

$ chmod -R 774 .

Après cela, vous devrez ajouter une nouvelle propriété équivalente à --shared = group effectuée pour le nouveau référentiel, selon la documentation, cela rend le référentiel accessible en écriture de groupe, exécutez-le:

$ git config core.sharedRepository group

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

Essayez de faire ce qui suit:

Accédez à votre serveur

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

Accédez ensuite à votre copie de travail (référentiel local) et reconditionnez-la en git repack master

Fonctionne parfaitement pour moi.

vous pouvez utiliser ceci

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

sudo su root

chown -R user:group dir

Le dir est votre dépôt git.

Alors fais:

git pull origin master

Vous verrez les changements concernant les commits par d'autres.

 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 - il s'est avéré que c'était un problème d'autorisations sur GitHub qui s'est produit lors du fork de emi / bixo vers bixo / bixo. Une fois que Tekkub a résolu ces problèmes, il a recommencé à fonctionner.

Étant donné que l'erreur concerne les autorisations sur le dossier d'objets, j'ai fait un chown directement sur le dossier d'objets et cela a fonctionné pour moi.

Cela marche:

sudo chmod -R gituser.gituser objects

Je suppose que beaucoup comme moi se retrouvent dans des forums comme celui-ci lorsque le problème git décrit ci-dessus se produit. Cependant, il y a tellement de causes qui peuvent conduire au problème que je veux juste partager ce qui a causé mes problèmes aux autres, comme j'ai déjà appris d'en haut.

J'ai mes dépôts sur un NAS Linux de sitecom (n'achetez jamais de NAS de Sitecom, pleeaaase). J'ai un dépôt ici qui est cloné sur de nombreux ordinateurs mais auquel on m'a soudainement refusé de pousser. Récemment, j'ai installé un plugin pour que mon NAS puisse se présenter comme un serveur squeezebox.

Ce serveur recherche les médias à partager. Ce que je ne savais pas, c'est que, possible à cause d'un bogue, le serveur modifie le paramètre utilisateur et groupe pour squeeze: user pour tous les fichiers qu'il examine. Et ce sont TOUS les fichiers. Modifiant ainsi les droits que je devais pousser.

Le serveur est parti et les paramètres de droits appropriés sont rétablis et tout fonctionne parfaitement.

j'ai utilisé

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

Où myuser et mygroup hors cours doivent être remplacés par des paramètres appropriés pour votre système. essayez git: git ou gituser: gituser ou quelque chose d'autre que vous pourriez aimer.,

Vérifiez le dépôt: $ 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)

Notez qu'il y a une sous-chaîne 'git @' ici, elle demande à git de s'authentifier en tant que nom d'utilisateur 'git' sur le serveur distant. Si vous omettez cette ligne, git s'authentifiera sous un nom d'utilisateur différent, d'où cette erreur se produira.

Dans mon cas, il n'y avait pas d'authentification unifiée (par exemple dans le domaine + service de type AD) entre ma machine et le serveur virtuel git. Par conséquent, les utilisateurs et le groupe git sont locaux pour le serveur virtuel. Dans mon cas, mon utilisateur distant (que j'utilise pour me connecter au serveur distant) n'a tout simplement pas été ajouté au groupe git distant.

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

Après cela, vérifiez les autorisations comme décrit dans les articles ci-dessus ...

Avez-vous essayé sudo git push -u origin --all ? Parfois, c'est la seule chose dont vous avez besoin pour éviter ce problème. Il vous demande le mot de passe du système d'administration - celui que vous pouvez vous connecter à votre machine -, et c'est ce que vous devez pousser - ou valider, si c'est le cas.