Erreur Git: impossible d'ajouter à .git / logs / refs / remotes / origin / master: autorisation refusée

Question 1

J'ai un problème étrange que je n'arrive pas à résoudre. Voici ce qui s'est passé:

J'avais des fichiers journaux dans un référentiel github que je ne voulais pas. J'ai trouvé ce script qui supprime complètement les fichiers de l'historique de git comme ceci:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Bien sûr, j'ai d'abord fait une sauvegarde, puis je l'ai essayé. Cela semblait bien fonctionner. J'ai ensuite fait un git push -f et j'ai été accueilli avec les messages suivants:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Tout semble s'être bien déroulé, car les fichiers semblent avoir disparu du référentiel GitHub, si j'essaye de pousser à nouveau, j'obtiens la même chose:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

ÉDITER

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Merci!

ÉDITER

Oh oh. Problème. J'ai travaillé sur ce projet toute la nuit et je suis juste allé valider mes changements:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Donc je:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

J'essaye à nouveau le commit et j'obtiens:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Donc je:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

Et puis j'essaye à nouveau le commit:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To [email protected]:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Hourra. Je saute sur http://GitHub.com et vérifie le référentiel, et mon dernier commit ne se trouve nulle part. :: scratch head :: Alors je pousse à nouveau:

Everything up-to-date

Hum ... ça ne ressemble pas à ça. Je n'ai jamais eu ce problème auparavant, est-ce que cela pourrait être un problème avec github? ou ai-je gâché quelque chose avec mon projet git?

ÉDITER

Peu importe, j'ai fait un simple:

git push origin master

et ça a bien poussé.

Question 2

On dirait que vous avez exécuté git en tant que root localement, changeant ainsi la propriété de certains des fichiers qui suivent l'emplacement de la originbranche.

Corrigez la propriété du fichier, et tout devrait bien se passer:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .

Question 3

Concentrons-nous sur ce dont il se plaint exactement:

Erreur d'autorisation refusée: impossible de mettre à jour la référence 'refs / remotes / origin / master'.

Avant de faire des changements de mod / propriété récursifs, parcourez votre chemin vers ce fichier et corrigez toutes les autorisations incorrectes.

Je pense que j'ai causé ce problème en créant une branche alors que j'étais root, puis en essayant de jouer avec cette branche en tant qu'utilisateur.

Question 4

Dans mon cas, j'ai créé les fichiers avec l'autorisation root localement et j'ai essayé de pousser le code à distance avec des autorisations locales. Alors j'ai exécuté cette commande

$find . -user root

pour savoir quels fichiers ont "root" comme propriétaire. Et puis j'ai changé de propriétaire pour tous les fichiers sous racine en local en utilisant la commande suivante

$sudo chown parineethat `find . -user root`

Ensuite, j'ai pu pousser mon code de local à distant.

Question 5

Cela changera tous vos fichiers et répertoires .git de manière récursive (de la racine à 1000) et vous donnera une liste complète de toutes les modifications apportées dans le terminal.

sudo chown -Rc $ UID .git /

Question 6

J'ai essayé de réparer la propriété de Git, mais cela ne fonctionne toujours pas.

Mais, j'ai réussi à le réparer en créant la branche locale avec un nom différent et en la supprimant.

Ensuite, je vérifie à nouveau le même nom de branche et cela fonctionne.

TLDR;

Je ne peux pas commander `staging / rc '.

Donc, je vérifie en utilisant à la stagingplace que la télécommande pointe vers `staging / rc '.

Et, je le supprime et je checkout à nouveau Mais, cette fois, j'utilise staging/rccomme nom de ma succursale locale.

Cela fonctionne et je ne sais pas pourquoi.

Question 7

Veuillez d'abord donner les autorisations du rootcompte comme ci-dessous

chmod -R 777 foldername

après cela, exécutez la commande commit

Answer 1

J'ai un problème étrange que je n'arrive pas à résoudre. Voici ce qui s'est passé:

J'avais des fichiers journaux dans un référentiel github que je ne voulais pas. J'ai trouvé ce script qui supprime complètement les fichiers de l'historique de git comme ceci:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Bien sûr, j'ai d'abord fait une sauvegarde, puis je l'ai essayé. Cela semblait bien fonctionner. J'ai ensuite fait un git push -f et j'ai été accueilli avec les messages suivants:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Tout semble s'être bien déroulé, car les fichiers semblent avoir disparu du référentiel GitHub, si j'essaye de pousser à nouveau, j'obtiens la même chose:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

ÉDITER

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Merci!

ÉDITER

Oh oh. Problème. J'ai travaillé sur ce projet toute la nuit et je suis juste allé valider mes changements:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Donc je:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

J'essaye à nouveau le commit et j'obtiens:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Donc je:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

Et puis j'essaye à nouveau le commit:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To [email protected]:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Hourra. Je saute sur http://GitHub.com et vérifie le référentiel, et mon dernier commit ne se trouve nulle part. :: scratch head :: Alors je pousse à nouveau:

Everything up-to-date

Hum ... ça ne ressemble pas à ça. Je n'ai jamais eu ce problème auparavant, est-ce que cela pourrait être un problème avec github? ou ai-je gâché quelque chose avec mon projet git?

ÉDITER

Peu importe, j'ai fait un simple:

git push origin master

et ça a bien poussé.

Answer 2

216

On dirait que vous avez exécuté git en tant que root localement, changeant ainsi la propriété de certains des fichiers qui suivent l'emplacement de la originbranche.

Corrigez la propriété du fichier, et tout devrait bien se passer:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .

Charles Duffy
la source

1

Cette commande a fonctionné pour moi. Je l'ai exécuté à partir de la racine du clone. Merci @CharlesDuffy!

ariestav

4

@ Mr.Stranger, uniquement si vous avez une valeur IFS et un nom d'utilisateur sains (les noms d'utilisateur avec des espaces peuvent arriver, par exemple sur cygwin). Plus sûr de citer:, sudo chown -R "$USER" .et de ne pas supposer la raison. :)

Charles Duffy

@ Mr.Stranger, ... également, USERn'est pas garanti par pubs.opengroup.org/onlinepubs/009695399/utilities/… , donc il pourrait être plus sûr à utiliser "$(id -un)".

Charles Duffy

Il dit à mon utilisateur is not in the sudoers file. This incident will be reported.- un conseil sur ce que je peux faire? Merci.

giovannipds

1

La syntaxe ci-dessus est l' expansion des paramètres ; "${var:-default}"se développe jusqu'à la valeur de la variable "$var", sauf si cette valeur est vide ou non définie, auquel cas elle se résout en default. Ainsi, nous développons soit vers "$USER", soit la sortie générée en exécutant id -un.

Charles Duffy

Answer 3

1

Cette commande a fonctionné pour moi. Je l'ai exécuté à partir de la racine du clone. Merci @CharlesDuffy!

ariestav

Answer 4

4

@ Mr.Stranger, uniquement si vous avez une valeur IFS et un nom d'utilisateur sains (les noms d'utilisateur avec des espaces peuvent arriver, par exemple sur cygwin). Plus sûr de citer:, sudo chown -R "$USER" .et de ne pas supposer la raison. :)

Charles Duffy

Answer 5

@ Mr.Stranger, ... également, USERn'est pas garanti par pubs.opengroup.org/onlinepubs/009695399/utilities/… , donc il pourrait être plus sûr à utiliser "$(id -un)".

Charles Duffy

Answer 6

Il dit à mon utilisateur is not in the sudoers file. This incident will be reported.- un conseil sur ce que je peux faire? Merci.

giovannipds

Answer 7

1

La syntaxe ci-dessus est l' expansion des paramètres ; "${var:-default}"se développe jusqu'à la valeur de la variable "$var", sauf si cette valeur est vide ou non définie, auquel cas elle se résout en default. Ainsi, nous développons soit vers "$USER", soit la sortie générée en exécutant id -un.

Charles Duffy

Answer 8

Concentrons-nous sur ce dont il se plaint exactement:

Erreur d'autorisation refusée: impossible de mettre à jour la référence 'refs / remotes / origin / master'.

Avant de faire des changements de mod / propriété récursifs, parcourez votre chemin vers ce fichier et corrigez toutes les autorisations incorrectes.

Je pense que j'ai causé ce problème en créant une branche alors que j'étais root, puis en essayant de jouer avec cette branche en tant qu'utilisateur.

Answer 9

3

Est-ce vraiment une amélioration de réparer les fichiers appartenant à quelqu'un d'autre que l'utilisateur censé posséder l'intégralité de l'arborescence source un par un?

Charles Duffy

Answer 10

Dans mon cas, j'ai créé les fichiers avec l'autorisation root localement et j'ai essayé de pousser le code à distance avec des autorisations locales. Alors j'ai exécuté cette commande

$find . -user root

pour savoir quels fichiers ont "root" comme propriétaire. Et puis j'ai changé de propriétaire pour tous les fichiers sous racine en local en utilisant la commande suivante

$sudo chown parineethat `find . -user root`

Ensuite, j'ai pu pousser mon code de local à distant.

Answer 11

sudo chown parineethat `find . -user root` n'est pas fiable - ne fonctionnera pas correctement avec les noms de fichiers avec des espaces. Au lieu de cela, sudo find . -user root -exec chown parineethat {} +. Voir BashPitfalls # 1 pour une discussion pertinente.

Charles Duffy

Answer 12

Cela changera tous vos fichiers et répertoires .git de manière récursive (de la racine à 1000) et vous donnera une liste complète de toutes les modifications apportées dans le terminal.

sudo chown -Rc $ UID .git /

Answer 13

J'ai essayé de réparer la propriété de Git, mais cela ne fonctionne toujours pas.

Mais, j'ai réussi à le réparer en créant la branche locale avec un nom différent et en la supprimant.

Ensuite, je vérifie à nouveau le même nom de branche et cela fonctionne.

TLDR;

Je ne peux pas commander `staging / rc '.

Donc, je vérifie en utilisant à la stagingplace que la télécommande pointe vers `staging / rc '.

Et, je le supprime et je checkout à nouveau Mais, cette fois, j'utilise staging/rccomme nom de ma succursale locale.

Cela fonctionne et je ne sais pas pourquoi.

Answer 14

-16

Veuillez d'abord donner les autorisations du rootcompte comme ci-dessous

chmod -R 777 foldername

après cela, exécutez la commande commit

Viru
la source

7

C'est extrêmement dangereux - cela donne à n'importe quel compte sur le système, y compris un démon compromis avec seulement les privilèges "personne", un accès en écriture à vos fichiers. Les démons système utilisent "nobody" (ou d'autres comptes non privilégiés) pour les composants sensibles à la sécurité car le compte nobody n'est pas censé pouvoir faire quoi que ce soit de trop risqué même s'il est compromis. En permettant à tous les utilisateurs, même à personne, d'avoir un accès en écriture à vos fichiers, vous rendez inutiles les mesures de sécurité essentielles.

Charles Duffy

1

Si, pour une raison quelconque, vous vouliez que vos fichiers appartiennent à root et soient accessibles en écriture par un utilisateur non root spécifique, le moyen le plus sûr de le faire (sur un système où chaque utilisateur a son propre groupe, comme c'est la pratique courante) est de chown -R root:user directory, et then chmod -R 775 directory(ou 770, si d'autres comptes n'ont pas besoin d'un accès en lecture non plus).

Charles Duffy

1

@JasonGlisson, quelque chose qui "fonctionne" uniquement en créant des failles de sécurité massives est probablement quelque chose qui ferait mieux de rester brisé.

Charles Duffy

1

@JasonGlisson, dans la mesure où nous fournissons des conseils à la fois en tant que communauté et à une communauté, en tant que membre de cette communauté, le type et la qualité des conseils que nous fournissons sont mon affaire autant que quiconque - et, en tant que personne travaillant dans la sécurité , Je suis bien placé pour commenter le sujet. Voir le commentaire initial, re: impact.

Charles Duffy

1

@JasonGlisson, ... quant à savoir pourquoi mon conseil n'a pas fonctionné pour vous, j'aurais besoin de voir les détails - un journal des commandes exécutées, dans l'ordre, avec une invite indiquant le répertoire de travail actuel avant chacune; texte de toute erreur émise; etc - afin de commenter; mais le lieu de cette discussion serait attaché à la réponse pour laquelle vous signalez de mauvais résultats, par opposition à ici.

Charles Duffy

Answer 15

7

C'est extrêmement dangereux - cela donne à n'importe quel compte sur le système, y compris un démon compromis avec seulement les privilèges "personne", un accès en écriture à vos fichiers. Les démons système utilisent "nobody" (ou d'autres comptes non privilégiés) pour les composants sensibles à la sécurité car le compte nobody n'est pas censé pouvoir faire quoi que ce soit de trop risqué même s'il est compromis. En permettant à tous les utilisateurs, même à personne, d'avoir un accès en écriture à vos fichiers, vous rendez inutiles les mesures de sécurité essentielles.

Charles Duffy

Answer 16

1

Si, pour une raison quelconque, vous vouliez que vos fichiers appartiennent à root et soient accessibles en écriture par un utilisateur non root spécifique, le moyen le plus sûr de le faire (sur un système où chaque utilisateur a son propre groupe, comme c'est la pratique courante) est de chown -R root:user directory, et then chmod -R 775 directory(ou 770, si d'autres comptes n'ont pas besoin d'un accès en lecture non plus).

Charles Duffy

Answer 17

1

@JasonGlisson, quelque chose qui "fonctionne" uniquement en créant des failles de sécurité massives est probablement quelque chose qui ferait mieux de rester brisé.

Charles Duffy

Answer 18

1

@JasonGlisson, dans la mesure où nous fournissons des conseils à la fois en tant que communauté et à une communauté, en tant que membre de cette communauté, le type et la qualité des conseils que nous fournissons sont mon affaire autant que quiconque - et, en tant que personne travaillant dans la sécurité , Je suis bien placé pour commenter le sujet. Voir le commentaire initial, re: impact.

Charles Duffy

Answer 19

1

@JasonGlisson, ... quant à savoir pourquoi mon conseil n'a pas fonctionné pour vous, j'aurais besoin de voir les détails - un journal des commandes exécutées, dans l'ordre, avec une invite indiquant le répertoire de travail actuel avant chacune; texte de toute erreur émise; etc - afin de commenter; mais le lieu de cette discussion serait attaché à la réponse pour laquelle vous signalez de mauvais résultats, par opposition à ici.

Charles Duffy

Erreur Git: impossible d'ajouter à .git / logs / refs / remotes / origin / master: autorisation refusée

Réponses:

TLDR;