Essayer de générer une erreur avec l'erreur: impossible d'ouvrir .git / FETCH_HEAD: autorisation refusée
Aidez-moi s'il vous plaît, j'essaye d'exécuter ceci dans mon terminal:
asgard@asgard-A7N8X2-0:~/CollegePortal$ git pull
error: cannot open .git/FETCH_HEAD: Permission denied
Puis j'essaye celui-ci
asgard@asgard-A7N8X2-0:~/CollegePortal$ Sudo git pull
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Aidez-moi, je ne comprends pas ce problème.
Il semble que le premier ne fonctionne pas car votre utilisateur ne dispose pas des autorisations nécessaires pour changer de répertoire, et le second parce que votre utilisateur root ne dispose pas des clés SSH appropriées pour accéder à ce référentiel git.
Selon ce que vous essayez de faire, il peut être préférable de cloner le référentiel dans un répertoire différent, ou peut-être chown le répertoire actuel pour avoir un accès complet à votre utilisateur.
Vérifiez si vous avez suffisamment d'autorisations sur le répertoire .git/. Vous devriez avoir des autorisations d'écriture. Vous pouvez les définir avec la commande suivante.
Allez dans votre dossier de projet:
chown -R youruser:yourgroup .git/
Si vous voulez donner la permission au groupe,
Sudo chmod g+w .git -R
a fonctionné mieux pour moi.
Pour MacOS
Sudo chmod -R g+w .git
Ceci est un problème d'autorisation UNIX. N'utilisez pas Sudo pour cloner le référentiel. Vous n'avez pas les mêmes clés ssh que root et vous ne devriez pas travailler en tant que root de toute façon. Essayez ls -la pour trouver les permissions sur les fichiers et utilisez chmod (ou Sudo chown) pour les corriger. J'espère que ça t'as aidé.
La réponse à ce problème assurez-vous que .git/FETCH_HEAD dispose des privilèges en écriture et que vous serez prêt.
J'ai eu ce problème sur Windows et il a été résolu en donnant des autorisations d'écriture.
Sous Unix, vous pouvez exécuter chmod a+rw .git/FETCH_HEAD à partir du référentiel de projet, après quoi cela devrait fonctionner.
Dans mon cas, ça marche bien après:
rm -f .git/FETCH_HEAD
Essayez comme ça,
Étape 1: Vérifiez d'abord qui vous êtes? il retournera le nom d'utilisateur actuel, par exemple bunt
$ whoami
Étape 2: Puis définissez l'autorisation sur votre utilisateur actuel, dans ce cas, bunt par
Sudo chown -R ubuntu .git/
Dans mon cas, je n'avais qu'un accès en lecture au fichier .git/FETCH_HEAD. Je devais faire "Sudo chmod g + w .git/FETCH_HEAD" afin de pouvoir faire une demande de tirage.
J'avais le premier problème (permission FETCH_HEAD refusée) sous Windows.
Je l'ai corrigé en exécutant Git Bash en tant qu'administrateur (clic droit, exécuter en tant qu'administrateur).
Si vous ne vous êtes pas ajouté au groupe qui possède .git/, alors vous devriez le faire.
Sudo usermod -a -G $(stat -c '%G' .git) $USER
Sudo chmod g+u .git -R
Sudo chmod g+u .gitignore
su - $USER
Qu'est-ce que cela fait:
- recherche le groupe qui possède
.git/et ajoute votre utilisateur à ce groupe. - s'assure que les membres du groupe ont les mêmes autorisations que le propriétaire de
.git/. - répète ceci pour
.gitignore, dont vous aurez probablement besoin - vous déconnecte et vous reconnecte pour actualiser les autorisations de votre fichier d'appartenance à un groupe
Si vous venez de faire quelque chose comme ceci (vous-même ajouté au groupe qui possède .git/), vous devez vous déconnecter et vous reconnecter avant de pouvoir écrire à .git/FETCH_HEAD pendant votre git pull.
Définissez l'autorisation sur votre utilisateur actuel en exécutant la commande
$ Sudo chown -R <username> .git/
Sous Windows 7, lorsque je rencontrais ce problème, c’était parce que j’avais caché le dossier .git. Les autorisations étaient bonnes, c'était juste caché. Affichage du dossier résolu.
Cela a fonctionné pour moi:
- Clic droit dossier .git
- cliquez sur obtenir des informations
- définir l'autorisation à votre utilisateur
- cliquez sur l'icône Cog et cliquez sur appliquer aux éléments inclus
Plus de permission refusée des erreurs dans git. ????
Les raisons de cette erreur peuvent être multiples, mais dans mon cas, j’ai mis à jour la branche avec root puis, quand j’ai essayé de le mettre à jour avec un utilisateur normal, cela me donne une erreur.
essayez les deux solutions on devrait travailler pour vous
1- Sudo chmod g+w .git -R
si cela ne fonctionne pas, veuillez essayer la solution suivante en espérant que cela résoudra votre problème.
2 - rm -f .git/FETCH_HEAD
Allez simplement dans votre dossier racine et lancez cette commande:
chmod a+rw .git/FETCH_HEAD
Regardez le propriétaire et le groupe du répertoire .git avec (allez d'abord dans le répertoire parent de .git) ll .git, regardez le groupe et le propriétaire du répertoire, ajoutez votre utilisateur au groupe du propriétaire avec Sudo usermod -a -G yourusername groupsofonwner, puis déconnexion => login et tout le travail.
Donc en été
aller au répertoire parent de git
$cd your pathrechercher le propriétaire du groupe du répertoire
.git$ll .gitajoutez votre utilisateur à ce groupe
$usermod -a -G yourusername ownergroupofgitDéconnectez-vous et connectez-vous au système pour que cette modification prenne effet.
Profitez-en ;)
Vous avez ce problème lorsque le dossier .git est masqué et que tous les fichiers qu'il contient sont également masqués. Ne faites que le dossier .git caché sans mettre à jour les fichiers récursifs et cela fonctionnera.
Dans mon cas,
Sudo chmod ug + wx .git -R
cette commande fonctionne.
J'ai eu ce message lors de l'utilisation d'extensions git pour Windows. Ma solution était simplement de fermer les extensions git puis de rouvrir en tant qu'administrateur
Ce problème survient lorsque vous ne donnez pas les autorisations suffisantes au dossier .git. Pour résoudre ce problème-
- Naviguez d’abord dans votre répertoire de travail.
Entrez cette commande-
Sudo chmod a + rw .git -R
J'espère que ça aide..!!
Je l'ai eu parce que j'avais plus d'un compte utilisateur sur ma boîte. J'étais connecté en tant qu'utilisateur A et j'étais dans un répertoire pour l'utilisateur B. L'utilisateur A n'était pas autorisé à accéder aux données de l'utilisateur B. Une fois que j'ai réalisé que je n'étais pas là où je pensais être dans le système de fichiers, cette erreur a eu un sens.
si vous rencontrez le même problème dans Windows Server, vous devez exécuter la ligne de commande avec suffisamment d'autorisations, telles que les autorisations d'administrateur.