Question Erreur Git Push: autorisation insuffisante pour ajouter un objet à la base de données du référentiel


Lorsque j'essaie de pousser vers une télécommande git partagée, j'obtiens l'erreur suivante: insufficient permission for adding an object to repository database

Ensuite, j'ai lu sur un correctif ici: Réparer  Cela a fonctionné pour la prochaine poussée, car tous les fichiers étaient du bon groupe, mais la prochaine fois que quelqu'un a modifié une modification, il a créé un nouvel élément dans le dossier des objets dont le groupe par défaut était leur groupe. La seule chose à laquelle je peux penser est de changer tous les groupes par défaut du développeur pour les éléments qu'ils enregistrent, mais cela semble être un hack. Des idées? Merci.


457
2018-06-23 00:58


origine


Réponses:


Autorisations de réparation

Une fois que vous avez identifié et corrigé la cause sous-jacente (voir ci-dessous), vous souhaitez réparer les autorisations:

cd /path/to/repo.git
chgrp -R groupname .
chmod -R g+rwX .
find . -type d -exec chmod g+s '{}' +

Si vous ne corrigez pas la cause sous-jacente, l'erreur continuera à revenir et vous devrez continuer à réexécuter les commandes ci-dessus encore et encore.

Des causes sous-jacentes

L'erreur peut être provoquée par l'un des éléments suivants:

  • Le référentiel n'est pas configuré pour être un référentiel partagé (voir core.sharedRepository dans git help config). Si la sortie de:

    git config core.sharedRepository
    

    n'est pas group ou true ou 1 ou un masque, essayez de courir:

    git config core.sharedRepository group
    

    puis réexécutez le récursif chmod et chgrp (voir "Réparer les autorisations" ci-dessus).

  • Le système d'exploitation n'interprète pas un bit setgid sur les répertoires car "tous les nouveaux fichiers et sous-répertoires doivent hériter du propriétaire du groupe".

    Quand core.sharedRepository est true ou group, Git s'appuie sur une fonctionnalité des systèmes d'exploitation GNU (par exemple, chaque distribution Linux) pour s'assurer que les sous-répertoires nouvellement créés appartiennent au bon groupe (le groupe dans lequel se trouvent tous les utilisateurs du référentiel). Cette fonctionnalité est documentée dans le Documentation de GNU coreutils:

    ... [Si] le bit set-group-ID d'un répertoire est défini, les sous-fichiers nouvellement créés héritent du même groupe que le répertoire et les sous-répertoires nouvellement créés héritent du bit set-group-ID du répertoire parent. ... [Ce mécanisme permet aux utilisateurs de partager des fichiers plus facilement, en réduisant le besoin d'utiliser chmod ou chown partager de nouveaux fichiers

    Cependant, tous les systèmes d'exploitation n'ont pas cette fonctionnalité (NetBSD en est un exemple). Pour ces systèmes d'exploitation, vous devez vous assurer que tous vos utilisateurs Git ont le même groupe par défaut. Sinon, vous pouvez rendre le dépôt accessible en écriture dans le monde entier en exécutant git config core.sharedRepository world (mais attention, c'est moins sécurisé).

  • Le système de fichiers ne prend pas en charge le bit setgid (par exemple, FAT). ext2, ext3, ext4 tous supportent le bit setgid. Pour autant que je sache, les systèmes de fichiers qui ne prennent pas en charge le bit setgid ne supportent pas non plus le concept de propriété de groupe, de sorte que tous les fichiers et répertoires appartiennent au même groupe (quel groupe est une option de montage). Dans ce cas, assurez-vous que tous les utilisateurs Git appartiennent au groupe qui possède tous les fichiers du système de fichiers.
  • Tous les utilisateurs Git ne sont pas dans le même groupe que les répertoires de référentiel. Assurez-vous que le propriétaire du groupe sur les répertoires est correct et que tous les utilisateurs sont dans ce groupe.

688
2018-06-23 01:13



Pour Ubuntu (ou n'importe quel Linux)

De la racine du projet,

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

Vous pouvez dire ce que votre nom et votre groupe devraient être en regardant les autorisations sur la majorité des résultats de cette commande ls -al

Note: rappelez-vous l'étoile à la fin de la ligne sudo


334
2017-10-21 13:04



Je voulais juste ajouter ma solution. J'ai eu un repo sur OS X qui possédait root sur certains répertoires et Home (qui est mon répertoire utilisateur) sur les autres, ce qui a provoqué la même erreur que celle indiquée ci-dessus.

La solution était simple, heureusement. À partir du terminal:

sudo chown -R Home projectdirectory

22
2018-02-14 18:18



sudo chmod -R ug+w .;

Fondamentalement, .git/objects le fichier n'a pas d'autorisations d'écriture. La ligne ci-dessus accorde l'autorisation à tous les fichiers et dossiers du répertoire.


22
2017-12-23 06:40



Une bonne façon de déboguer ceci est la prochaine fois, SSH dans le repo distant, cd dans le dossier des objets et faire un ls -al.

Si vous voyez 2 ou 3 fichiers avec des utilisateurs différents: la propriété du groupe est le problème.

Il m'est arrivé par le passé avec certains scripts hérités d'accéder à notre dépôt git et signifie généralement qu'un utilisateur différent (unix) a poussé / modifié des fichiers en dernier et que votre utilisateur n'est pas autorisé à remplacer ces fichiers. Vous devez créer un groupe git partagé dans lequel tous les utilisateurs de git sont activés, puis récursivement chgrp la objects dossier et son contenu pour que la propriété du groupe soit partagée git groupe.

Vous devez également ajouter un bit sticky dans le dossier afin que tous les fichiers créés dans le dossier aient toujours le groupe de git.

chmod g + s nom-répertoire

Mise à jour: je ne connaissais pas core.sharedRepository. Bon à savoir, même si cela ne fait probablement que ce qui précède.


15
2018-06-23 03:49



Cela peut facilement arriver si vous avez couru git init avec un utilisateur différent de celui que vous prévoyez d'utiliser lors de la modification des modifications.

Si vous suivez aveuglément les instructions sur [1], cela se produira car vous avez probablement créé l'utilisateur git en tant que root, puis vous êtes immédiatement passé à git init sans changer d'utilisateur entre les deux.

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server 


8
2017-09-05 12:12



Résolu pour moi ... juste ça:

sudo chmod 777 -R .git/objects

6
2017-09-04 10:47