Erreur push Git: 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 un correctif ici: Fix Cela a fonctionné pour la prochaine poussée, car tous les fichiers étaient du bon groupe, mais la prochaine fois que quelqu'un a poussé une modification, il a fait un nouvel élément dans le dossier des objets qui avait leur groupe par défaut en tant que groupe. La seule chose à laquelle je peux penser est de changer tout le groupe par défaut du développeur pour les éléments qu'ils archivent, mais cela semble être un hack. Des idées? Merci.

Autorisations de réparation

Après avoir identifié et corrigé la cause sous-jacente (voir ci-dessous), vous souhaiterez réparer les autorisations:

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

Notez que si vous voulez que tout le monde puisse modifier le référentiel, vous n'avez pas besoin de chgrpet vous voudrez changer le chmod ensudo chmod -R a+rwX .

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

Des causes sous-jacentes

L'erreur peut être due à l'un des éléments suivants:

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

  git config core.sharedRepository
  

  n'est pas groupou trueou 1ou un masque, essayez d'exécuter:

  git config core.sharedRepository group
  

  puis réexécutez le récursif chmodet 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.sharedRepositoryest trueou group, Git s'appuie sur une fonctionnalité des systèmes d'exploitation GNU (par exemple, chaque distribution Linux) pour garantir 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 la documentation 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 la nécessité d'utiliser chmodou chownde 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. Alternativement, vous pouvez rendre le référentiel accessible en écriture en exécutant git config core.sharedRepository world(mais soyez prudent, c'est moins sécurisé).

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

Pour Ubuntu (ou tout Linux)

Depuis la racine du projet,

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

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

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

utilisez la commande suivante, fonctionne comme par magie

sudo chown -R "${USER:-$(id -un)}" .

tapez la commande exactement comme elle est (avec des espaces supplémentaires et un point à la fin)

sudo chmod -R ug+w .;

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

Je voulais juste ajouter ma solution. J'avais un dépôt sur OS X qui possédait la propriété de root sur certains répertoires et de Home (qui est mon répertoire utilisateur) sur d'autres, ce qui a provoqué la même erreur répertoriée ci-dessus.

Heureusement, la solution était simple. Depuis le terminal:

sudo chown -R Home projectdirectory

Une bonne façon de déboguer ceci est la prochaine fois que cela se produit, SSH dans le référentiel distant, cd dans le dossier des objets et faites un ls -al.

Si vous voyez 2-3 fichiers avec un utilisateur différent: propriété du groupe, c'est le problème.

Cela m'est arrivé dans 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é les fichiers en dernier et que votre utilisateur n'a pas les autorisations pour écraser ces fichiers. Vous devez créer un groupe git partagé dans lequel se trouvent tous les utilisateurs compatibles git, puis récursivement chgrple objectsdossier et son contenu afin que la propriété du groupe soit le gitgroupe partagé .

Vous devez également ajouter un élément collant sur 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.

Résolu pour moi ... juste ceci:

sudo chmod 777 -R .git/objects

Cela peut facilement se produire si vous avez exécuté git initavec un utilisateur différent de celui que vous prévoyez d'utiliser lors de la transmission des modifications.

Si vous suivez aveuglément les instructions de [1], cela se produira car vous avez probablement créé git-user 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

Linux, macOS:

cd .git/
sudo chown -R name:group *

où nameest votre nom d'utilisateur et groupest le groupe auquel appartient votre nom d'utilisateur.

Après avoir ajouté des trucs ... engagez-les et après tout, poussez-les! COUP!! Commencez tous les problèmes ... Comme vous devez le remarquer, il existe des différences dans la définition des projets nouveaux et existants. Si une autre personne essaie d'ajouter / valider / pousser les mêmes fichiers ou contenus (git conserve les deux comme les mêmes objets), nous ferons face à 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 lui dans ce cas. Vous comprenez mieux 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 modifier ... *

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 aller de l'avant et modifier toutes les autorisations par 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, selon la documentation, cela rendra le groupe du référentiel accessible en écriture, exécutez-le:

$ git config core.sharedRepository group

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

Pour mon cas, aucune des suggestions n'a fonctionné. Je suis sous Windows et cela a fonctionné pour moi:

• Copiez le référentiel distant dans un autre dossier
• Partagez le dossier et accordez les autorisations appropriées.
• Assurez-vous que vous pouvez accéder au dossier à partir de votre ordinateur local.
• Ajoutez ce référentiel comme un autre référentiel distant dans votre référentiel local. ( git remote add foo //SERVERNAME/path/to/copied/git)
• Poussez à foo. git push foo master. Cela a-t-il fonctionné? Génial! Maintenant, supprimez le référentiel qui ne fonctionne pas et renommez-le en ce qu'il était auparavant. Assurez-vous que les autorisations et la propriété de partage restent les mêmes.

J'ai touché ce même problème. En lisant ici, j'ai réalisé que c'était les autorisations de fichiers auxquelles le message faisait référence. Le correctif, pour moi, était:

/etc/inetd.d/git-gpv

Il commençait git-daemon en tant qu'utilisateur ' nobody ' donc n'avait pas l'autorisation d'écriture.

# Who   When    What
# GPV   20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV   20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo

(Je doute que d'autres appellent leur fichier de configuration inetd git-gpv. Généralement, ce serait directement dans /etc/inetd.conf)

Vous avez besoin des autorisations d'écriture suffisantes sur le répertoire vers lequel vous appuyez.

Dans mon cas: serveur Windows 2008

clic droit sur le répertoire git repo ou le répertoire parent.

Propriétés> onglet Partage> Partage avancé> Autorisations> assurez-vous que l'utilisateur dispose des droits d'accès appropriés.

Vous pouvez avoir des référentiels git imbriqués accidentellement

Il est également possible que vous ayez ajouté un autre référentiel local avec le même alias. Par exemple, vous avez maintenant 2 dossiers locaux appelés originainsi lorsque vous essayez de pousser, le référentiel distant n'acceptera pas vos informations d'identification.

Renommez les alias du référentiel local, vous pouvez suivre ce lien https://stackoverflow.com/a/26651835/2270348

Vous pouvez peut-être laisser 1 référentiel local de votre choix au fur originet à mesure que les autres les renomment par exemple de originà anotherorigin. N'oubliez pas que ce ne sont que des alias et que tout ce que vous avez à faire est de vous souvenir des nouveaux alias et de leurs branches distantes respectives.

Travaille pour moi

sudo chmod -R g+rwX .

Je l'ai obtenu en entrant dans un projet Rstudio. J'ai réalisé que j'avais oublié de faire:

sudo rstudio

au démarrage du programme. En fait, comme il y a un autre bug que j'ai, je dois réellement faire:

sudo rstudio --no-sandbox

Utilisez sudo pour commit -m

• git add -A
• sudo git commit -m "Utiliser sudo pour commit -m"
• git push origin nom_branche

J'obtenais ce problème avec un référentiel distant sur un partage Samba; J'ai réussi à tirer de cette télécommande, mais j'ai échoué en poussant dessus.

La cause de l'erreur était des informations d'identification incorrectes dans mon ~/.smbcredentialsfichier.