web-dev-qa-db-fra.com

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

Lorsque j'essaie d'envoyer un message à une télécommande git partagée, le message d'erreur suivant s'affiche: insufficient permission for adding an object to repository database

Ensuite, j’ai lu un article sur un correctif ici: Fix Cela fonctionnait pour le prochain Push, car tous les fichiers appartenaient au bon groupe, mais la prochaine fois que quelqu'un insérait un changement, il créait un nouvel élément dans le fichier. le dossier des objets ayant leur groupe par défaut comme 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'il enregistre, mais cela semble être un hack. Des idées? Merci.

gitpush
547
skaz

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 chgrp et vous voulez changer le chmod en Sudo chmod -R a+rwX .

Si vous ne corrigez pas la cause sous-jacente, l'erreur continuera à apparaître 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 lancer:

    git config core.sharedRepository group

    puis relancez les commandes chmod et chgrp récursives (voir "Réparer les autorisations" ci-dessus).

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

    Lorsque core.sharedRepository est true ou group, Git s'appuie sur une fonctionnalité de GNU systèmes d'exploitation (par exemple, chaque distribution Linux) pour s'assurer que les sous-répertoires nouvellement créés appartiennent à le 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 ID-groupe-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 ID-groupe-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 pour partager de nouveaux fichiers.

    Cependant, tous les systèmes d'exploitation ne disposent pas de 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. Vous pouvez également rendre le référentiel accessible en écriture au monde en exécutant git config core.sharedRepository world (mais soyez prudent, cela est moins sécurisé).

  • Le système de fichiers ne prend pas en charge le bit setgid (par exemple, FAT). ext2, ext3, ext4 supportent tous le bit setgid. Autant que je sache, les systèmes de fichiers qui ne prennent pas en charge le bit setgid ne prennent pas non plus en charge le concept de propriété de groupe, de sorte que tous les fichiers et répertoires seront toujours détenus par le même groupe (ce groupe est une option de montage). Dans ce cas, assurez-vous que tous les utilisateurs Git sont dans le groupe qui possède tous les fichiers du système de fichiers.
  • Tous les utilisateurs de Git ne font pas partie du même groupe que celui qui est propriétaire des répertoires du 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.
800
Richard Hansen

Pour Ubuntu (ou n'importe quel Linux)

De la racine du projet,

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

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

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

400
TerryS

Sudo chmod -R ug+w .;

Fondamentalement, le fichier .git/objects ne dispose pas d’autorisation en écriture. La ligne ci-dessus accorde l’autorisation à tous les fichiers et dossiers du répertoire.

44
Rajendra kumar Vankadari

utilisez la commande suivante, fonctionne comme par magie

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

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

37
Code_Worm

Je voulais juste ajouter ma solution. J'avais un référentiel sous OS X qui possédait la propriété root sur certains répertoires et Home (qui est mon répertoire utilisateur) sur d'autres, ce qui entraînait la même erreur que celle indiquée ci-dessus.

La solution était simple heureusement. Du terminal:

Sudo chown -R Home projectdirectory
27
Brandon

Un bon moyen 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 effectuez un ls -al.

Si vous voyez 2 ou 3 fichiers avec un utilisateur différent: la propriété du groupe est le problème.

C'est ce qui m'est arrivé dans le passé avec certains scripts hérités qui accèdent à notre dépôt Git. Cela signifie généralement qu'un fichier différent (unix) poussé/modifié est utilisé en dernier et que votre utilisateur ne dispose pas des autorisations nécessaires pour écraser ces fichiers. Vous devez créer un groupe git partagé dans lequel se trouvent tous les utilisateurs activés pour git, puis récursivement chgrp le dossier objects et son contenu afin que la propriété du groupe soit le groupe partagé git.

Vous devez également ajouter un sticky bit sur le dossier afin que tous les fichiers créés dans ce dossier aient toujours le groupe 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.

18
Mauvis Ledford

Résolu pour moi ... juste ceci:

Sudo chmod 777 -R .git/objects
13
GUSTAVO BERBERT

Cela peut facilement arriver si vous avez exécuté git init avec 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 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

9
gitzor

Linux, macOS:

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

où name est votre nom d'utilisateur et group est le groupe auquel appartient votre nom d'utilisateur.

6
Afshin Mehrabani

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 quelques 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

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

5
helmedeiros

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

  • Copiez le dépôt distant dans un autre dossier
  • Partagez le dossier et donnez les autorisations appropriées.
  • Assurez-vous que vous pouvez accéder au dossier à partir de votre ordinateur local.
  • Ajoutez ce dépôt comme autre dépôt distant dans votre dépôt local. (git remote add foo //SERVERNAME/path/to/copied/git)
  • Poussez à foo. git Push foo master. Cela a-t-il fonctionné? Génial! Supprimez maintenant le dépôt non ouvrable et renommez-le comme auparavant. Assurez-vous que les autorisations et la propriété de partage restent les mêmes.
3
Halil Kaskavalci

Je frappe le même problème. En lisant ici, j'ai réalisé que c'était le fichier auquel le message faisait référence. La solution, pour moi, était dans:

/etc/inetd.d/git-gpv

Il commençait par lancer git-daemon en tant qu'utilisateur 'personne' qui ne disposait donc pas de l'autorisation en é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)

2
GraemeV

Vous devez disposer des autorisations d'écriture suffisantes sur le répertoire dans lequel vous souhaitez effectuer la compression.

Dans mon cas: serveur Windows 2008

faites un 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.

1
Fuyu Persimmon

Il est également possible que vous ayez ajouté un autre référentiel local avec le même alias. Par exemple, vous avez maintenant deux dossiers locaux appelés Origin. Par conséquent, lorsque vous essayez d'envoyer des données en mode Push, 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 un répertoire local de votre choix sous le nom Origin et les autres le renommer, par exemple de Origin à anotherorigin. Rappelez-vous que ce ne sont que des alias et tout ce que vous avez à faire est de vous rappeler les nouveaux alias et leurs branches distantes respectives.

1
Huey Mataruse

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

1
IliasT

Travaille pour moi

Sudo chmod -R g+rwX .
0
Nitin Tyagi

Je l'ai eu 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 le faire:

Sudo rstudio --no-sandbox
0
Timothy Pollington