web-dev-qa-db-fra.com

git: ne peut pas pousser (erreur de décompression) liée à des problèmes d'autorisation

J'ai ce problème quand j'essaye de pousser en git:

error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://<repo url>/<repo dir>
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to Push some refs to 'ssh://<repo url>/<repo dir>'

J'ai déjà eu cela sporadiquement auparavant et nous avons toujours eu à le résoudre par chaque utilisateur en envoyant un message au référentiel et en définissant des autorisations de groupe pour tous les fichiers qu'il contient. 

chmod -R g+w *

Cela n’a jamais été une solution satisfaisante et maintenant, il nous a mordus au point qu’un des gars est absent et que personne ne connaît le mot de passe de son utilisateur. Donc, j'essaie de le résoudre correctement. 

L'erreur semble se produire lorsque quelqu'un essaie d'insérer une modification qui modifiera un répertoire de dépôt détenu par un autre utilisateur (par conséquent, définissez l'option d'écriture de groupe ci-dessus). J'ai fait quelques recherches sur Google et j'ai trouvé quelques solutions en cours de discussion (aucune de ces solutions ne fonctionnant pour moi).

1) assurez-vous que le groupe avec lequel les répertoires de référent sont partagés est le groupe principal de chaque utilisateur (je pense que c'est déjà le cas: chaque utilisateur n'a qu'un groupe, ce qui doit donc être leur groupe principal, n'est-ce pas?)

2) Paramétrage de git repo core.sharedRepository, comme détaillé ici: Git: impossible d’envoyer depuis un ordinateur J’ai modifié cela, mais cela n’a pas changé. Dois-je recharger la configuration ou quelque chose pour réellement effectuer le changement?

Voici ce que ma confo repo ressemble à atm:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedRepository = all
[receive]
        denyNonFastForwards = True

Reconnaissant pour tout conseil ou suggestion! Max

linuxgit
49
Max Williams

Une méthode plus simple consiste à ajouter un script de post-réception qui exécute la commande chmod Après chaque transmission au référentiel 'hub' du serveur. Ajoutez la ligne suivante à hooks/post-receive dans votre dossier git sur le serveur:

chmod -Rf u+w /path/to/git/repo/objects
26
spadeworkers

J'ai eu cette erreur pendant deux semaines, et la majorité des solutions ont indiqué la réponse «chmod -R», malheureusement pour moi, mes dépôts git (local/distant/partagé - avec l'équipe) étaient tous sous Windows, et même si chmod -Rv a montré que tous les fichiers ont été modifiés en "rwxrwxrwx", un "ls -l" ultérieur a encore indiqué que tous les fichiers étaient "rwxr-xr-x" et que l'erreur se répétait. J'ai finalement vu cette solution par Ariejan de Vroom. Cela a fonctionné et nous avons tous pu tirer et pousser à nouveau.

Sur le local (le local qui a du mal à pousser) et sur le dépôt distant, exécutez les commandes suivantes:

$ git fsck
$ git Prune
$ git repack
$ git fsck

Par ailleurs, j’ai essayé d’utiliser les permissions de fichier/ACL natives de Windows et j’ai même décidé d’élever l’utilisateur problématique en tant qu’administrateur, mais rien de tout cela n’a semblé aider. Vous n'êtes pas sûr que l'environnement soit important, mais cela peut aider une personne ayant une configuration similaire - membre de l'équipe problématique et distante (Windows Server 2008 R2 Standard), ma locale (VM 7).

18
Jason Robinson

C'est une erreur de permission. Le moyen le plus approprié et le plus sûr pour moi était d'ajouter des utilisateurs à un groupe supplémentaire que le repo. appartient à (ou vice versa):

groupadd git
chgrp -R git .git
chgrp -R git ./
usermod -G -a git $(whoami)
8
Alastair

Dans le cas où quelqu'un d'autre est coincé avec ceci: cela signifie simplement l'écriture les autorisations sont incorrectes dans le référentiel vers lequel vous souhaitez pousser. Allez et chmod -R pour que l’utilisateur auquel vous accédez au serveur git ait un accès en écriture.

http://blog.shamess.info/2011/05/06/remote-rejected-na-unpacker-error/

Ça fonctionne.

5
sjas

Pour moi, cette erreur est survenue alors que ma télécommande était saturée.

Je voulais juste lire le reste du message d'erreur:

error: file write error (No space left on device)
fatal: unable to write sha1 file
error: unpack failed: unpack-objects abnormal exit
3
aradil

J'utilise la gitose pour gérer ce genre de choses. Gitosis a un seul utilisateur (généralement appelé "git") qui possède tous les référentiels et utilise un contrôle d'accès basé sur une clé publique pour chaque référentiel. Cela pourrait ne pas convenir à votre configuration, mais cela vaut probablement la peine de vérifier (sans jeu de mots).

3
Cameron Skinner

Ce problème peut également se produire après les mises à niveau Ubuntu nécessitant un redémarrage.

Si le fichier /var/run/reboot-required existe, effectuez ou planifiez un redémarrage.

1
cmc

J'avais également des problèmes avec cela, pensant que mon gitolite-admin à distance était corrompu ou quelque chose de faux. 

Ma configuration est un ordinateur portable Mac OS X (10.6.6) avec un serveur distant Ubuntu 10 avec gitolite.

Il s’est avéré que le problème venait de mon local checkout de gitolite-admin. 

Malgré l'erreur "Unpack Failed", le problème était local.

Je l'ai compris en vérifiant à nouveau qu'il s'agit de gitolite-admin2, en effectuant un changement et en le poussant. 

Voila! Ça a marché!

1
jpswain

Pour ce que ça vaut, j'ai eu le même problème avec mon propre VPS et cela était causé par le manque d'espace disque sur VPS. Confirmé par la commande df -h et après avoir nettoyé le disque dur de mon VPS; le problème était parti.

À votre santé.

1
dariush

Pour moi, c'est un problème de permissions:

Sur le serveur git, exécutez cette commande dans le répertoire repo.

Sudo chmod -R 777 theDirectory/
0
MobileMon

Là où je travaille, nous utilisons cette méthode sur tous nos référentiels depuis quelques années sans aucun problème (sauf lorsque nous créons un nouveau référentiel et oublions de le configurer de cette manière):

  1. Définissez 'sharedRepository = true' dans la section '[core]' du fichier de configuration.

  2. Remplacez l’ID de groupe du référentiel par un groupe partagé par tous les utilisateurs autorisés à y accéder:

    chgrp -R shared_group /git/our_repos
chmod -R g+w /git/our_repos

  3. Définissez le bit setgid sur tous les répertoires du référentiel afin que les nouveaux fichiers/répertoires conservent le même groupe:

    find /git/our_repos -type d -exec chmod g+s {} +

  4. Ajoutez cette ligne au hook de pré-réception dans le référentiel pour vous assurer que les nouvelles autorisations de fichiers autorisent le groupe en lecture/écriture:

    umask 007
0
Mark E. Hamilton

J'obtenais une erreur similaire et veuillez voir ci-dessous comment je l'ai résolue.

Ma structure de répertoire: /Opt/git/project.git et l'utilisateur git est git

$ cd /opt/git/project.git
$ Sudo chown -R git:git .

chown avec l'option -R modifie de manière récursive la propriété et le groupe (puisque j'ai saisi git: git dans la commande ci-dessus) du répertoire en cours. chown -R est nécessaire car git change de nombreux fichiers dans votre répertoire git lorsque vous accédez au référentiel.

0
Hrushikesh