2016-12-16 2 views
0

J'ai un problème avec ma configuration client/serveur git qui crée des problèmes d'autorisations lorsque plusieurs utilisateurs poussent des modifications. Mes utilisateurs obtiennent l'erreur:Git Windows Utilisateurs multiples - Autorisations de groupe Problème

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

Ma configuration Le dépôt git est situé sur un partage réseau NetApp. Ce partage réseau est monté sur un serveur Linux Red Hat (RHEL) 6.4. Pour créer le référentiel des journaux d'utilisateur dans le serveur RHEL, navigue à l'endroit où ils veulent que le dépôt (sur la part montée) puis exécutez la commande suivante:

git init --bare --shared=true repo.git 

Chaque utilisateur est travaille localement sur leur propre machine Windows 7/10 , ils ont des fenêtres git installées, et ils ont le partage réseau précédemment mentionné mappé comme un lecteur. Pour obtenir le dépôt sur leur machine, ils ouvrent git-bash et naviguent vers l'endroit où ils veulent cloner le repo localement. Ils courent alors:

git clone Z:/git_repo_location/repo.git 

La question Les utilisateurs sont en mesure de pousser les changements dans le dépôt et everythings fonctionne bien jusqu'à ce qu'ils tentent de pousser les changements dans un fichier qui quelqu'un d'autre avait déjà édité. C'est quand l'erreur énumérée ci-dessus dresse sa tête laide.

Passant en revue les autorisations de RHEL, il apparaît que les dossiers de repo.git/objets sont mis à 755. Je crois que ce qui se passe est quand un dossier d'objets appartient à l'utilisateur A, l'utilisateur B ne peut pas pousser modifications apportées aux fichiers affectés. En guise de note, tous les utilisateurs ont mis à jour leur umask dans git-bash à 0002 (à partir du 0022 par défaut). Tous les fichiers/dossiers du dépôt repo.git appartiennent également au groupe "DTG" et tous les utilisateurs travaillant sur ce dépôt appartiennent à ce groupe.

TENTATIVE Corrections J'ai essayé de créer/initialiser les dépôts de plusieurs autres façons, mais chacun a les mêmes résultats:

Create repo2.git 
    git init --bare repo2.git 
    cd repo2.git 
    git config core.sharedRepository group 
    chgrp -R dtg . 
    chmod -R g+w . 
    chmod g+s `find . -type d` 

Create repo3.git 
    git init --bare repo3.git 
    cd repo3.git  
    chgrp -R dtg . 
    chmod -R g+w . 
    chmod g+s `find . -type d` 
    git init --bare --shared=all 

Create repo4.git 
    git init --bare repo4.git 
    cd repo4.git 
    git config core.sharedRepository true  
    chgrp -R dtg . 
    chmod -R g+swX . 
    chmod g+s `find . -type d` 
    git init --bare --shared=all 

J'ai aussi essayé d'avoir les utilisateurs cloner le dépôt lors de la configuration de la configuration sharedRepository locale

git clone --config core.sharedRepository=true Z:/git_repo_location/repo.git 

jusqu'à présent, la seule chose qui résout ce problème est de savoir si je me connecte à la machine RHEL et ajouter l'autorisation du groupe aux dossiers d'objets:

chmod -R g+w repo.git/objects/ 

Le problème est que ce n'est qu'un pansement temporaire pour résoudre le problème immédiat. Mais dès que quelqu'un appuie de nouveau sur les changements, il me reste des dossiers d'objets qui manquent au groupe et qui permettent à l'utilisateur suivant d'être à nouveau bloqué.

Toute aide à ce sujet serait grandement appréciée !!! Aussi, si des informations supplémentaires sont nécessaires s'il vous plaît faites le moi savoir. La plupart des solutions tentées ci-dessus proviennent d'une autre question similaire How to configure an existing git repo to be shared by a UNIX group

+1

double possible de [Comment configurer un être partagé git existant par un groupe UNIX] (http: // stackoverflow. com/questions/3242282/how-to-configure-an-existing-git-repo-to-be-shared-by-unix-group) –

+2

en dehors de ce qui est un doublon: s'il vous plaît faire n ot poster des captures d'écran des messages de la console si vous aussi besoin d'aide de codeurs malvoyants. utilisez plutôt des blocs 'code' ou' quote'. –

+0

La plupart de mes solutions tentées sont dérivées du lien dupliqué possible que vous avez fourni. Peut-être qu'il y a quelque chose que j'ai manqué sur la page mais je n'ai pas pu trouver une solution à partir de ce post. Aussi, je vais prendre note de la recommandation d'écran pour les messages à venir !! –

Répondre

0

cela semble être un problème de la couche intermédiaire pour le partage de fichiers. en supposant que vous utilisez réellement SAMBA pour fournir un partage réseau à monter à partir des invités w32, les paramètres umask et similaires ne vous aideront pas beaucoup (puisque les autorisations sont réellement gérées par le serveur samba et le client w32 - ce dernier essayant souvent de faire des fichiers de très restrictives)

vous pourriez avoir la chance avec quelque chose comme:

[git] 
     comment = GIT repositories 
     path = /path/to/git/repos 
     read only = No 
     force group = dtg 
     create mask = 0664 
     directory mask = 0775 
     force directory mode = 0770 
     force create mode = 0660