Erreur lors de l'envoi à GitHub - autorisation insuffisante pour ajouter un objet à la base de données du référentiel
Je récupère une erreur inhabituelle en essayant de faire un "git Push" dans mon référentiel GitHub:
Comptage d'objets: 8, fait. Compression delta utilisant 2 threads. Compression d'objets: 100% (4/4), fait. Écriture d'objets: 100 % (5/5), 1,37 Ko, 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 d'objet erreur: unpack-objets sortis avec le code d'erreur 128 erreur: unpack échouant: unpack-objets, sortie anormale . Pour [email protected]: bixo/bixo.git ! [rejeté à distance] maître -> maître (n/a (erreur de décompression)) erreur: échec de l'envoi de références à '[email protected]: bixo/bixo.git'
- Après un clone pur de GitHub, je peux éditer/ajouter/commettre/Pousser un fichier modifié.
- Si je répète cela une seconde fois, j'obtiens l'erreur ci-dessus.
- Je peux très bien utiliser les autres dépôts GitHub.
- J'ai vérifié les autorisations de fichiers/répertoires de mon côté et elles semblent OK.
- J'utilise git 1.6.2.3 sur Mac OS X 10.5.8
Le référentiel ci-dessus était la source de mon amusement pour une précédente question de Stack Overflow ( SO 190486 ), alors peut-être que le référentiel GitHub a été corrompu. Le seul problème similaire que j'ai trouvé lors de la recherche était un problème problème d'échec de la décompression signalé sur github. Quelqu'un d’autre a-t-il déjà rencontré ce problème, en particulier lorsque n’utilise pas l’utilisation de GitHub?
Lorsque vous voyez cette erreur en dehors de github, voici un remède.
Je l'ai obtenu 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 devrait 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 votre serveur Git. Le référentiel git doit être la propriété de l'utilisateur et de son groupe.
Exemple:
Si votre utilisateur s'appelle "git", son groupe "gitgroup" et l'emplacement du référentiel Git est: [email protected]: chemin/à/repo.git
alors faites un:
Sudo chown -R git: chemin de gitgroup/to/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é de git pull. Certaines analyses ont montré que quelqu'un s'était déjà engagé avec root dans le passé, créant ainsi des objets avec une propriété racine dans .git/objects.
Alors j'ai couru
cd <repo>
la .git/objects/
et cela montrait root propriété pour certains objets (répertoires) comme ceci:
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 cela a fonctionné!
Je remplaçais tilisateur par mon vrai utilisateur, 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 repo du type
ssh://[email protected]/~git/repo.git
Malheureusement, j'ai enregistré une session PuTTY sous le nom example.com qui a été configuré pour se connecter en tant qu’utilisateur myOtherUser.
Alors, alors que je pensais que git se connecte à l'hôte example.com avec l'utilisateur 'git', Git/TortoiseGit s'est connecté à la session PuTTY example.com qui utilise l'utilisateur myOtherUser. Ceci conduit exactement au même ..insufficient permission.. erreur (car les deux utilisateurs sont dans des groupes différents).
Solution: renommer la session PuTTY example.com à [email protected]
chmod doit être chown, la ligne correcte est donc:
Sudo chown -R gituser:gituser objects
Je recevais cette erreur parce que chaque fois qu'un utilisateur envoie du contenu, le groupe du fichier est changé en utilisateur. Et puis, si un autre utilisateur essayait de transmettre dans le référentiel, cela entraînait une erreur d'autorisation et le transfert était rejeté. Il est donc nécessaire de demander à votre administrateur système de modifier les paramètres du référentiel afin que le groupe de tous les fichiers du référentiel ne soit pas modifié pour aucun Push effectué par un utilisateur.
Pour éviter ce problème, assurez-vous que lorsque vous initialisez votre référentiel git, utilisez la commande "git init --shared = group".
Curieusement, j'ai eu ce problème sur un clone du repo que j'avais, mais pas un autre que j'ai eu. En plus de re-cloner le référentiel (ce qu'un collègue a fait pour résoudre ce problème avec succès), j'ai réussi à effectuer une "réinitialisation de git" pour la validation que j'avais avant le début des échecs. Ensuite, j'ai ré-engagé les modifications et j'ai réussi à pousser Push après cela. Donc, malgré toutes les indications, il y avait un problème sur le serveur, dans ce cas, il était apparemment révélateur d'une bizarrerie dans le dépôt local.
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/
vous pouvez utiliser cela
Sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"
Sudo su root
chown -R user:group dir
Le dir est votre repo git.
Alors fais:
git pull Origin master
Vous verrez des changements sur les commits par d'autres.
Si vous obtenez toujours cette erreur plus tard après en définissant 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. Par conséquent, seule la personne qui les avait validés pouvait envoyer 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 milieu 0 permet l'écriture de groupe par défaut.
Après avoir ajouté des trucs ... commettez-les et, après tout, terminez-le! COUP!! Commencez tous les problèmes ... Comme vous devriez le constater, il existe des différences dans la définition des projets nouveaux et existants. Si une autre personne essaie d'ajouter/de valider/de transmettre les mêmes fichiers, ou du contenu (git garde les deux comme des objets identiques), l'erreur suivante sera générée:
$ 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 à l’esprit le système d’autorisations du système d’exploitation, qui vous limite dans ce cas. Pour mieux comprendre le problème, allez-y et vérifiez le dossier de votre objet git (.git/objects). 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 autorisations de ces fichiers ont été accordées uniquement 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 avez l'autorisation de super utilisateur, vous pouvez aller de l'avant et modifier toutes les autorisations vous-même en utilisant la deuxième étape. 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 procédant comme suit:
$ chmod -R 774 .
Après cela, vous devrez ajouter une nouvelle propriété équivalente à --shared = group effectuée pour le nouveau référentiel, conformément à la documentation, ce qui rend le référentiel accessible en écriture au groupe, exécutez-le:
$ git config core.sharedRepository group
Essayez de faire ce qui suit:
Allez sur 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 remballez-la en git repack master
Fonctionne parfaitement pour moi.
Je suppose que beaucoup, comme moi, finissent 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 pour les autres à apprendre comme je l'ai déjà appris plus haut.
J'ai mon repo sur un Linux NAS de sitecom (ne jamais acheter NAS de Sitecom, pleeaaase)). J'ai un repo ici qui est cloné sur de nombreux ordinateurs mais J'ai récemment installé un plugin pour que mon NAS puisse faire office de serveur Squeezebox.
Ce serveur analyse le contenu multimédia à partager. Ce que je ne savais pas, c’est que, possible à cause d’un bogue, le serveur modifie les paramètres de l’utilisateur et du groupe afin qu’ils soient compressés: utilisateur pour tous les fichiers qu’il examine. Et ce sont TOUS les fichiers. En modifiant ainsi les droits, 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 off-course doivent être remplacés par les paramètres appropriés pour votre système. essayez git: git ou gituser: gituser ou autre chose qui pourrait vous plaire.,
Dans mon cas, il n'y avait pas d'authentification unifiée (par exemple, dans le domaine + un 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 permissions comme décrit dans les posts ci-dessus ...
Étant donné que l'erreur concerne les autorisations sur le dossier d'objets, j'ai effectué un chown directement sur le dossier d'objets et cela a fonctionné pour moi.
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 administrateur - celui avec lequel vous pouvez vous connecter à votre machine -, et c'est ce dont vous avez besoin pour Push - ou pour le commettre, si c'est le cas.
Vérifiez le référentiel: $ git remote -v
Origin ssh://[email protected]:2283/srv/git/repo.git (fetch)
Origin ssh://[email protected]:2283/srv/git/repo.git (Push)
Notez qu'il y a une sous-chaîne 'git @' ici, il demande à git de s'authentifier sous le 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ù l'erreur se produira.
Cela marche:
Sudo chmod -R gituser.gituser objects
OK - s’avère que c’est un problème d’autorisations sur GitHub qui est survenu au cours de la conversion d’emi/bixo vers bixo/bixo. Une fois que Tekkub a corrigé ces problèmes, il a recommencé à fonctionner.