53 votes

Fatal: impossible de verrouiller le stockage des informations d'identification : Le fichier existe

Je suis en train d'utiliser git-scm et j'ai essayé de pousser vers un dépôt. En le faisant, j'ai été accueilli avec le message suivant:

fatal: unable to get credential storage lock: File exists

Alors que la poussée s'est finalement déroulée avec succès, je me demandais pourquoi cette erreur est apparue. Cela continue de se produire, et cela ne se produisait pas auparavant. Toute aide est appréciée. Merci!

5 votes

J'ai trouvé qu'il y a un fichier /c/Users/USERNAME/.git-credentials.lock - mais quand je le supprime, je reçois une erreur d'assertion la prochaine fois que j'exécute git, et il y a un nouveau fichier de verrouillage. Ce qui conduit à une nouvelle erreur "lock: File exists". J'ai également trouvé que j'avais deux paramètres (différents) pour credential.store, un dans mon répertoire personnel, et un autre dans /C/Program\ Files/Git/mingw64/etc/gitconfig. Supprimer ce dernier n'a rien changé, même si git config -l ne montre maintenant qu'un seul paramètre. Donc pour moi, ce problème reste un mystère. J'ai trouvé ceci: github.com/git-for-windows/git/issues/766

1 votes

Cela m'est arrivé après avoir "annulé" un git add ou commit. Si vous appuyez sur CTRL+C dans git bash.

40voto

Zhe He Points 314

J'ai eu le même problème aujourd'hui. Il s'est avéré que j'avais deux configurations pour credential.helper. Utilisez git config --list pour vérifier si vous avez plusieurs credential.helper="XXX".

Dans mon cas, j'avais credential.helper=manager dans la configuration globale et credential.helper=store dans la configuration locale.

J'ai supprimé la locale dans chemin-vers-le-projet-git/.git/config et résolu le problème.

0 votes

Pour moi, je pense que cela a à voir avec le nouveau gestionnaire d'informations d'identification avec les dernières versions de Git pour Windows. L'ancien paradigme était de définir credential.helper pour stocker et utiliser des clés d'authentification... maintenant, il semble que Git pour Windows gérera votre compte en direct en interne par défaut

8 votes

Cela a résolu mon problème. J'ai également trouvé git config --list --show-origin utile, et git config --WHICH --unset credential.helper où WHICH est l'emplacement de l'entrée problématique, c'est-à-dire local, global ou système.

14voto

Shqear Points 41

Essayez de configurer votre aide d'identification sans utiliser --global

git config credential.helper wincred

1 votes

Fonctionne comme un charme :)

7voto

torek Points 25463

Le message d'erreur provient de git credential-store (cliquez pour accéder à la page de documentation). Il indique qu'une autre instance du programme de stockage des informations d'identification est en cours d'exécution et a verrouillé le fichier qui stocke (de manière non sécurisée, en texte clair) votre mot de passe.

Si aucune autre instance de git credential-store n'est réellement en cours d'exécution, le fichier de verrouillage est sans aucun doute resté suite à une exécution précédente, et vous pouvez simplement le supprimer. Malheureusement, le programme ne vous indique pas l'emplacement du fichier de données d'identification spécifique (mais consultez la documentation pour les emplacements probables).

1voto

liberforce Points 4385

J'ai eu du mal à trouver où se trouvait le fichier de verrouillage. Sur Linux, il suffit d'utiliser strace, mais n'oubliez pas de suivre les processus enfants avec l'option -f:

strace -f -eopen git credential-store --file=~/mystore store < creds
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/dev/null", O_RDWR)               = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/home/g179531/.gitconfig", O_RDONLY) = 3
Processus 8269 attaché
[pid  8269] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[pid  8269] open("~/mystore.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = -1 ENOENT (Aucun fichier ou dossier de ce type)
fatal: impossible d'obtenir le verrou de stockage des identifiants: Aucun fichier ou dossier de ce type
[pid  8269] +++ sortie avec 128 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8269, si_status=128, si_utime=0, si_stime=0} ---
+++ sortie avec 128 ++

Le dernier fichier que le programme a essayé d'ouvrir avant d'afficher l'erreur est le fichier de verrouillage. Dans mon cas, c'est ~/mystore.lock.

0 votes

Cela m'a aidé avec mon erreur 'No such file or directory'. Il essayait d'interpréter ~ comme un dossier à l'intérieur du répertoire actuel.

0 votes

Sur mon système, il était dans ~/.git-credentials.lock

0 votes

Pour Windows, j'ai utilisé le moniteur de processus

1voto

Sonic Soul Points 4562

Dans mon cas sous Windows, un fichier git credentials .lock a été ajouté dans mon répertoire c:\users\xxxx où se trouvent toutes les configurations git globales.

j'ai supprimé le fichier de verrouillage, ce qui a également supprimé le fichier de credentials git qui stockait mon mot de passe en clair.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X