Erreur Git push: impossible de dissocier l'ancien (autorisation refusée)

205

Dans le serveur distant, j'ai un hook post-receive mis en place afin de faire une extraction git de mon référentiel:

#!/bin/sh
GIT_WORK_TREE=/var/www/<website> git checkout -f

Mais lorsque je fais un push de ma machine locale vers le référentiel git sur le serveur, j'obtiens les messages d'erreur suivants:

remote: error: unable to unlink old '<file>' (Permission denied)

Cela apparaît plusieurs fois, un message d'erreur pour presque chaque fichier.

Cependant, j'ai un fichier README.txt que je peux modifier en utilisant git, voici ses autorisations:

-rw-r--r--  1 <serverusername>  <serverusername>  2939 Aug  2 10:58 README.txt

Mais d'autres fichiers avec exactement le même propriétaire et les mêmes autorisations me donnent cette erreur.

Dans un autre référentiel local pour un autre site Web, j'ai les fichiers avec le nom d'utilisateur de ma machine locale en tant que propriétaire, et lorsque je pousse vers le serveur distant, il respecte le propriétaire du serveur distant des fichiers et fonctionne comme un charme.

Évidemment, cela semble être une erreur liée aux autorisations, mais je ne trouve pas de moyen de la corriger, des suggestions?

rfc1484
la source

Réponses:

348

Lorsque vous devez dissocier un fichier, vous devez avoir l'autorisation 'w' pour le répertoire, dans quel fichier se trouve, pas pour le fichier ...

Jan Marek
la source
66
En effet, c'était le problème, je l'ai résolu en utilisant sudo chmod -R g+wsur les dossiers coupables.
rfc1484
1
Merci OMG. J'étais tellement ennuyé de penser que les autorisations étaient correctes sur le fichier. Il est logique que les mises à jour ressemblent plus à des mvactions qu'à de simples écrasements.
doublejosh
1
La modification des autorisations de répertoire a fonctionné pour moi (merci!) Mais c'est étrange car je pouvais écraser manuellement les fichiers en question via sftp sans aucun problème. Étrange que quand git ait essayé de faire de même, il ne puisse pas.
Jonathan Stark
1
Gardez également à l'esprit que si le fichier est toujours ouvert, cette erreur apparaîtra également. J'ai eu la même erreur et c'est pourquoi je n'ai pas pu appliquer mes modifications.
Matias
1
Le premier caractère de l' ls -laffichage indique le type de fichier et n'est pas lié aux autorisations. Les neuf caractères restants sont répartis en trois ensembles, chacun représentant une classe d'autorisations en trois caractères. Le premier ensemble représente la classe d'utilisateurs. Le deuxième ensemble représente la classe de groupe. Le troisième ensemble représente les autres classes. Le g+wdans chmod donne au groupe défini (le gparamètre) l'autorisation d'écrire (le wparamètre)
rfc1484
73
sudo chmod -R ug+w .;

Cette commande résoudrait le problème. Il donne des autorisations d'écriture sur le dossier.

Rajendra kumar Vankadari
la source
43

Si vous utilisez un IDE, le problème est probablement que le fichier a été utilisé par un processus. Comme votre chat utilise peut-être le fichier. Essayez d'identifier ce processus particulier et fermez-le. Cela devrait résoudre votre problème.

Rama Krishna Gollapudi
la source
18

Je pense que le problème peut être lié à la propriété du dossier, alors définissez-le sur la propriété actuelle de l'utilisateur

sudo chown -R your_login_name /path/to/folder
Vous pouvez trouver la solution [ici] [1]
Soumitra Sarkar
la source
Merci d'avoir sauvé ma journée
Reda Taha
14

J'ai eu le même problème et aucune des solutions ci-dessus n'a fonctionné pour moi. J'ai supprimé le dossier incriminé. Ensuite:

git reset --hard

Supprimé tous les fichiers en attente pour nettoyer l'état de git, puis a fait:

git pull

Cela a finalement fonctionné.

REMARQUE: si le dossier était, par exemple, un dossier public avec des fichiers de construction, n'oubliez pas de reconstruire les fichiers

wcyn
la source
Merci, rien d'autre ne fonctionnait pour moi non plus, sa suppression semblait être la seule option.
math0ne
Dans mon cas, ce dossier incriminé est .git
Tushar Kathuria
8

FWIW - J'ai eu un problème similaire et je ne suis pas sûr si cela l'a atténué (au-delà du mod d'autorisation): la fermeture d'Eclipse qui utilisait la branche avec ce problème.

cellepo
la source
De même, j'ai eu cette erreur lorsqu'un fichier CSV contrôlé par version était ouvert dans Excel. La simple fermeture d'Excel l'a résolu. Cela est probablement vrai pour d'autres applications sur Windows et dépend probablement de la façon dont le programme marque le fichier comme ouvert lors de l'édition.
Carel
5

C'est une vieille question, mais cela peut aider les utilisateurs de Mac.

Si vous copiez manuellement des fichiers depuis Time Machine, au lieu de les restaurer via Time Machine, cela ajoutera des ACL à tout, ce qui peut gâcher vos autorisations.

Par exemple, la section de cet article qui dit «Comment réparer les autorisations de fichiers Mac OS X» montre que «tout le monde» a des autorisations personnalisées, ce qui gâche tout:

Mauvaises autorisations, de http://dreamlight.com/how-to-fix-mac-os-x-file-permissions

Vous devez supprimer les ACL de ces répertoires / fichiers. Cette réponse de super utilisateur y va, mais voici la commande:

sudo chmod -RN .

Ensuite, vous pouvez vous assurer que vos répertoires et fichiers disposent des autorisations appropriées. J'utilise 750pour les répertoires et 644pour les fichiers.

kylesimmonds
la source
Merveilleuse réponse. Je cherchais exactement ceci pour un problème d'ACL mac lorsque les fichiers sont copiés manuellement.
Ankit Bhatnagar le
3

J'obtiens cette erreur, et d'autres erreurs git étranges, quand j'ai un serveur en cours d'exécution (dans Intellij). Arrêter le serveur et réessayer la commande git le corrige fréquemment pour moi.

Phil Carter
la source
3
git reset --hard

A travaillé pour moi

Kreker
la source
4
Cela pourrait être un peu extrême car cela fait beaucoup plus.
cdaddr
3

Le tirage a peut-être créé un changement local.

Ajoutez votre fichier non suivi:

git add.

Changements de réserve.

git stash

Abandonnez les modifications locales.

git stash drop

Tirez avec l'autorisation sudo

sudo git pull remote branch

user2858738
la source
tout est question de permission des fichiers locaux, il n'y a rien à voir avec git Je viens d'exécuter la commande avec sudo et cela a fonctionné, donc je n'ai pas besoin de toutes ces étapes
raviramani
3
sudo chown -R $USER:$USER .

A fait le travail pour moi.

BARJ
la source
2

Certains fichiers sont protégés en écriture et même git ne peut pas les écraser. Modifiez l'autorisation du dossier pour autoriser l'écriture, par exemple sudo chmod 775 nomdossier

Et puis exécutez

git pull 

encore

Carmela
la source
1

N'oubliez pas de vérifier également l'autorisation du répertoire racine lui-même!

Vous pouvez trouver:

drwxr-xr-x  9 not-you www-data  4096 Aug  8 16:36 ./
-rw-r--r--  1     you www-data  3012 Aug  8 16:36 README.txt
-rw-r--r--  1     you www-data  3012 Aug  8 16:36 UPDATE.txt

et l'erreur «permission refusée» apparaîtra.

cadavre
la source
0

Après avoir vérifié l'autorisation du dossier, tout va bien avec 744. J'ai eu un problème avec un plugin qui est installé sur mon site WordPress. Le plugin a accroché qui sont dans le travail de maïs que je soupçonnais.

Avec un simple sudo it can fix the issue

sudo git pull origin master

Vous le faites fonctionner.

pensebien
la source