Błąd Git: nie można dołączyć do .git / logs / refs / remotes / origin / master: Odmowa dostępu

Question 1

Mam dziwny problem, którego nie mogę rozwiązać. Oto, co się stało:

Miałem kilka plików dziennika w repozytorium github, których tam nie chciałem. Znalazłem ten skrypt, który całkowicie usuwa pliki z historii git w następujący sposób:

    #!/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

Oczywiście najpierw utworzyłem kopię zapasową, a następnie spróbowałem. Wydawało się, że działa dobrze. Następnie wykonałem git push -f i zostałem powitany następującymi komunikatami:

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

Wygląda na to, że wszystko poszło dobrze, ponieważ wydaje się, że pliki zniknęły z repozytorium GitHub, jeśli spróbuję ponownie i otrzymam to samo:

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

EDYTOWAĆ

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

Dzięki!

EDYTOWAĆ

O o. Problem. Pracowałem nad tym projektem całą noc i po prostu poszedłem zatwierdzić zmiany:

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

Więc ja:

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

Próbuję ponownie zatwierdzić i otrzymuję:

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

Więc ja:

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

A potem ponownie próbuję zatwierdzić:

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

Brawo. Wskakuję na http://GitHub.com i sprawdzam repozytorium, a mojego ostatniego zatwierdzenia nie ma gdzie znaleźć. :: drap się po głowie :: Więc znowu pcham:

Everything up-to-date

Umm ... na to nie wygląda. Nigdy wcześniej nie miałem tego problemu, czy to może być problem z githubem? czy może coś zepsułem z moim projektem git?

EDYTOWAĆ

Nieważne, zrobiłem proste:

git push origin master

i działało dobrze.

Question 2

Wygląda na to, że uruchomiłeś lokalnie git jako root, zmieniając w ten sposób własność niektórych plików śledzących lokalizację origingałęzi.

Napraw własność pliku i wszystko powinno być w porządku:

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

Question 3

Skoncentrujmy się na tym, na co dokładnie narzeka:

Błąd odmowy uprawnień: nie można zaktualizować referencji „refs / remotes / origin / master”.

Przed dokonaniem cyklicznych zmian modyfikacji / własności przejdź do tego pliku i napraw wszelkie nieprawidłowe uprawnienia.

Myślę, że spowodowałem ten problem, tworząc gałąź, gdy byłem rootem, a następnie próbując zadzierać z tą gałęzią jako mój użytkownik.

Question 4

W moim przypadku utworzyłem pliki z uprawnieniami roota lokalnie i próbowałem wypchnąć kod do zdalnego z uprawnieniami lokalnymi. Więc uruchomiłem to polecenie

$find . -user root

aby dowiedzieć się, jakie pliki mają właściciela „root”. A potem zmieniłem właściciela wszystkich plików, które są w katalogu głównym, na lokalne za pomocą następującego polecenia

$sudo chown parineethat `find . -user root`

Wtedy mogłem przesłać mój kod z lokalnego na zdalny.

Question 5

Spowoduje to rekursywną zmianę wszystkich twoich plików i katalogów .git (od roota do 1000) i da ci pełną listę wszystkich zmian dokonanych w terminalu.

sudo chown -Rc $ UID .git /

Question 6

Próbowałem naprawić własność Git, ale nadal nie działa.

Ale udało mi się to naprawić, tworząc oddział lokalny o innej nazwie i usuwając go.

Następnie ponownie sprawdzam tę samą nazwę gałęzi i działa.

TLDR;

Nie mogę pobrać pliku `staging / rc '.

Więc sprawdzam, używając stagingzamiast tego, że pilot wskazuje na `staging / rc '.

Usuwam go i ponownie płacę. Ale tym razem używam staging/rcnazwy mojego lokalnego oddziału.

Działa i nie mam pojęcia, dlaczego.

Question 7

Najpierw podaj uprawnienia z rootkonta, jak poniżej

chmod -R 777 foldername

po tym uruchom komendę commit

Answer 1

Mam dziwny problem, którego nie mogę rozwiązać. Oto, co się stało:

Miałem kilka plików dziennika w repozytorium github, których tam nie chciałem. Znalazłem ten skrypt, który całkowicie usuwa pliki z historii git w następujący sposób:

    #!/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

Oczywiście najpierw utworzyłem kopię zapasową, a następnie spróbowałem. Wydawało się, że działa dobrze. Następnie wykonałem git push -f i zostałem powitany następującymi komunikatami:

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

Wygląda na to, że wszystko poszło dobrze, ponieważ wydaje się, że pliki zniknęły z repozytorium GitHub, jeśli spróbuję ponownie i otrzymam to samo:

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

EDYTOWAĆ

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

Dzięki!

EDYTOWAĆ

O o. Problem. Pracowałem nad tym projektem całą noc i po prostu poszedłem zatwierdzić zmiany:

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

Więc ja:

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

Próbuję ponownie zatwierdzić i otrzymuję:

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

Więc ja:

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

A potem ponownie próbuję zatwierdzić:

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

Brawo. Wskakuję na http://GitHub.com i sprawdzam repozytorium, a mojego ostatniego zatwierdzenia nie ma gdzie znaleźć. :: drap się po głowie :: Więc znowu pcham:

Everything up-to-date

Umm ... na to nie wygląda. Nigdy wcześniej nie miałem tego problemu, czy to może być problem z githubem? czy może coś zepsułem z moim projektem git?

EDYTOWAĆ

Nieważne, zrobiłem proste:

git push origin master

i działało dobrze.

Answer 2

219

Wygląda na to, że uruchomiłeś lokalnie git jako root, zmieniając w ten sposób własność niektórych plików śledzących lokalizację origingałęzi.

Napraw własność pliku i wszystko powinno być w porządku:

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

Charles Duffy
źródło

1

To polecenie zadziałało dla mnie. Uruchomiłem go z katalogu głównego klona. Dzięki @CharlesDuffy!

ariestav

4

@ Panie Nieznajomy, tylko jeśli masz rozsądną wartość IFS i nazwę użytkownika (nazwy użytkowników ze spacjami mogą się zdarzyć, na przykład na cygwin). Bezpieczniej cytować: sudo chown -R "$USER" .i nie zakładać rozsądku. :)

Charles Duffy

@ Mr. Stranger, ... również USERnie jest gwarantowane przez pubs.opengroup.org/onlinepubs/009695399/utilities/… , więc może być bezpieczniejsze w użyciu "$(id -un)".

Charles Duffy

Mówi o moim użytkowniku is not in the sudoers file. This incident will be reported.- jakaś wskazówka na temat tego, co mogę zrobić? Dzięki.

giovannipds

1

Powyższa składnia to interpretacja parametrów ; "${var:-default}"rozwija się do wartości zmiennej "$var", chyba że ta wartość jest pusta lub nieustawiona, w takim przypadku jest rozwiązywana na default. W ten sposób albo rozwijamy do "$USER", albo dane wyjściowe generowane przez uruchomienie id -un.

Charles Duffy

Answer 3

1

To polecenie zadziałało dla mnie. Uruchomiłem go z katalogu głównego klona. Dzięki @CharlesDuffy!

ariestav

Answer 4

4

@ Panie Nieznajomy, tylko jeśli masz rozsądną wartość IFS i nazwę użytkownika (nazwy użytkowników ze spacjami mogą się zdarzyć, na przykład na cygwin). Bezpieczniej cytować: sudo chown -R "$USER" .i nie zakładać rozsądku. :)

Charles Duffy

Answer 5

@ Mr. Stranger, ... również USERnie jest gwarantowane przez pubs.opengroup.org/onlinepubs/009695399/utilities/… , więc może być bezpieczniejsze w użyciu "$(id -un)".

Charles Duffy

Answer 6

Mówi o moim użytkowniku is not in the sudoers file. This incident will be reported.- jakaś wskazówka na temat tego, co mogę zrobić? Dzięki.

giovannipds

Answer 7

1

Powyższa składnia to interpretacja parametrów ; "${var:-default}"rozwija się do wartości zmiennej "$var", chyba że ta wartość jest pusta lub nieustawiona, w takim przypadku jest rozwiązywana na default. W ten sposób albo rozwijamy do "$USER", albo dane wyjściowe generowane przez uruchomienie id -un.

Charles Duffy

Answer 8

Skoncentrujmy się na tym, na co dokładnie narzeka:

Błąd odmowy uprawnień: nie można zaktualizować referencji „refs / remotes / origin / master”.

Przed dokonaniem cyklicznych zmian modyfikacji / własności przejdź do tego pliku i napraw wszelkie nieprawidłowe uprawnienia.

Myślę, że spowodowałem ten problem, tworząc gałąź, gdy byłem rootem, a następnie próbując zadzierać z tą gałęzią jako mój użytkownik.

Answer 9

3

Czy naprawianie plików, które są własnością kogokolwiek innego niż użytkownik, który oczekuje, że będzie właścicielem całego drzewa źródłowego, jest naprawdę postępem?

Charles Duffy

Answer 10

W moim przypadku utworzyłem pliki z uprawnieniami roota lokalnie i próbowałem wypchnąć kod do zdalnego z uprawnieniami lokalnymi. Więc uruchomiłem to polecenie

$find . -user root

aby dowiedzieć się, jakie pliki mają właściciela „root”. A potem zmieniłem właściciela wszystkich plików, które są w katalogu głównym, na lokalne za pomocą następującego polecenia

$sudo chown parineethat `find . -user root`

Wtedy mogłem przesłać mój kod z lokalnego na zdalny.

Answer 11

sudo chown parineethat `find . -user root` jest zawodny - nie będzie działał poprawnie z nazwami plików ze spacjami. Zamiast tego sudo find . -user root -exec chown parineethat {} +. Odpowiednią dyskusję znajdziesz w BashPitfalls # 1 .

Charles Duffy,

Answer 12

Spowoduje to rekursywną zmianę wszystkich twoich plików i katalogów .git (od roota do 1000) i da ci pełną listę wszystkich zmian dokonanych w terminalu.

sudo chown -Rc $ UID .git /

Answer 13

Próbowałem naprawić własność Git, ale nadal nie działa.

Ale udało mi się to naprawić, tworząc oddział lokalny o innej nazwie i usuwając go.

Następnie ponownie sprawdzam tę samą nazwę gałęzi i działa.

TLDR;

Nie mogę pobrać pliku `staging / rc '.

Więc sprawdzam, używając stagingzamiast tego, że pilot wskazuje na `staging / rc '.

Usuwam go i ponownie płacę. Ale tym razem używam staging/rcnazwy mojego lokalnego oddziału.

Działa i nie mam pojęcia, dlaczego.

Answer 14

-16

Najpierw podaj uprawnienia z rootkonta, jak poniżej

chmod -R 777 foldername

po tym uruchom komendę commit

Viru
źródło

7

Jest to niezwykle niebezpieczne - daje każdemu kontu w systemie, w tym przejętemu demonowi z uprawnieniami tylko „nikt”, prawo do zapisu w twoich plikach. Demony systemowe używają „nobody” (lub innych nieuprzywilejowanych kont) dla komponentów wrażliwych na bezpieczeństwo, ponieważ konto nobody nie powinno być w stanie zrobić niczego zbyt ryzykownego, nawet jeśli jest zagrożone. Pozwalając wszystkim użytkownikom, nawet nikomu, na dostęp do plików w trybie zapisu, sprawiasz, że podstawowe środki bezpieczeństwa stają się bezużyteczne.

Charles Duffy

1

Jeśli z jakiegoś powodu chciałeś, aby twoje pliki były własnością roota i mogły być zapisywane przez określonego użytkownika innego niż root, bezpiecznym sposobem na zrobienie tego (w systemie, w którym każdy użytkownik ma własną grupę, zgodnie ze standardową praktyką) jest chown -R root:user directoryi następnie chmod -R 775 directory(lub 770, jeśli inne konta również nie potrzebują dostępu do odczytu).

Charles Duffy

1

@JasonGlisson, coś, co „działa” tylko poprzez tworzenie ogromnych luk w zabezpieczeniach, jest prawdopodobnie czymś, co byłoby lepsze, gdyby nie zostało zepsute.

Charles Duffy

1

@JasonGlisson, o ile udzielamy porad zarówno jako społeczności, jak i jej członkom, jakiego rodzaju i jakości doradzamy w takim samym stopniu jak moja firma - i jako osoba zajmująca się bezpieczeństwem , Jestem dobrze przygotowany do skomentowania tematu. Zobacz wstępny komentarz, re: impact.

Charles Duffy

1

@JasonGlisson, ... jeśli chodzi o to, dlaczego moja rada nie zadziałała, potrzebowałbym zobaczyć szczegóły - dziennik poleceń uruchamianych w kolejności z monitem pokazującym bieżący katalog roboczy przed każdym; tekst wszystkich wyświetlonych błędów; etc - w celu komentowania; ale miejsce na tę dyskusję byłoby związane z odpowiedzią, dla której zgłaszasz złe wyniki, w przeciwieństwie do tutaj.

Charles Duffy

Answer 15

7

Jest to niezwykle niebezpieczne - daje każdemu kontu w systemie, w tym przejętemu demonowi z uprawnieniami tylko „nikt”, prawo do zapisu w twoich plikach. Demony systemowe używają „nobody” (lub innych nieuprzywilejowanych kont) dla komponentów wrażliwych na bezpieczeństwo, ponieważ konto nobody nie powinno być w stanie zrobić niczego zbyt ryzykownego, nawet jeśli jest zagrożone. Pozwalając wszystkim użytkownikom, nawet nikomu, na dostęp do plików w trybie zapisu, sprawiasz, że podstawowe środki bezpieczeństwa stają się bezużyteczne.

Charles Duffy

Answer 16

1

Jeśli z jakiegoś powodu chciałeś, aby twoje pliki były własnością roota i mogły być zapisywane przez określonego użytkownika innego niż root, bezpiecznym sposobem na zrobienie tego (w systemie, w którym każdy użytkownik ma własną grupę, zgodnie ze standardową praktyką) jest chown -R root:user directoryi następnie chmod -R 775 directory(lub 770, jeśli inne konta również nie potrzebują dostępu do odczytu).

Charles Duffy

Answer 17

1

@JasonGlisson, coś, co „działa” tylko poprzez tworzenie ogromnych luk w zabezpieczeniach, jest prawdopodobnie czymś, co byłoby lepsze, gdyby nie zostało zepsute.

Charles Duffy

Answer 18

1

@JasonGlisson, o ile udzielamy porad zarówno jako społeczności, jak i jej członkom, jakiego rodzaju i jakości doradzamy w takim samym stopniu jak moja firma - i jako osoba zajmująca się bezpieczeństwem , Jestem dobrze przygotowany do skomentowania tematu. Zobacz wstępny komentarz, re: impact.

Charles Duffy

Answer 19

1

@JasonGlisson, ... jeśli chodzi o to, dlaczego moja rada nie zadziałała, potrzebowałbym zobaczyć szczegóły - dziennik poleceń uruchamianych w kolejności z monitem pokazującym bieżący katalog roboczy przed każdym; tekst wszystkich wyświetlonych błędów; etc - w celu komentowania; ale miejsce na tę dyskusję byłoby związane z odpowiedzią, dla której zgłaszasz złe wyniki, w przeciwieństwie do tutaj.

Charles Duffy

Błąd Git: nie można dołączyć do .git / logs / refs / remotes / origin / master: Odmowa dostępu

Odpowiedzi:

TLDR;