Ostrzeżenie Git Checkout: nie można odłączyć plików, odmowa uprawnień

109

Zdaję sobie sprawę, że istnieją podobne problemy z git związane z ostrzeżeniem „nie można odłączyć”, ale nie mogłem z nich skorzystać.

Główna różnica polega na tym, że działo się to wtedy, gdy w żaden sposób nie miałem do czynienia z modułami podrzędnymi (nigdy wcześniej nie miałem z nimi do czynienia). Stworzyłem gałąź o nazwie „upgrade”, usunąłem moje stare pliki frameworka i skopiowałem do nowych. Użyłem git add -A, a potem popełniłem wszystko. Kiedy próbowałem wyewidencjonować gałąź trunk, odpowiedziała następującymi błędami:

warning: unable to unlink requirements/views/sk/index.php: Permission denied
warning: unable to unlink requirements/views/sv/index.php: Permission denied
warning: unable to unlink requirements/views/zh/index.php: Permission denied
warning: unable to unlink requirements/views/zh_cn/index.php: Permission denied
warning: unable to unlink requirements/views/zh_tw/index.php: Permission denied

...itp. Są ich setki.

Na początku myślałem, że to po prostu problem z uprawnieniami, więc dodałem rekursywnie uprawnienia do zapisu grupowego do całego katalogu wymagań, ale nie było zmian.

Edycja: jak zasugerowałem w odpowiedzi poniżej, próbowałem zrobić to samo, ale wszystko inne było zamknięte. Nie miałem więcej szczęścia niż wcześniej.

Ten problem jest szczególnie osłabiający, ponieważ nie mogę przejść do pnia, aby wrócić do normalnego rozwoju.

Wzór doskonałości
źródło
9
Rozwiązałem to prostymsudo chown -R username directory
Stephen Corwin

Odpowiedzi:

84

Zwykle widzę ten rodzaj błędu, gdy proces nie zwalnia uchwytu tych plików.

Upewnij się, że nic nie działa, a następnie spróbuj ponownie zapłacić.

Uwaga: może to być również związane ze sposobem, w jaki zainstalowano Git (w systemie Windows UAC może generować problem, jeśli msysgit jest zainstalowany w C:\Programlub C:\Program Files, zobacz " msysgit - sh.exe - fork: Odmowa uprawnień - Vista 64-bitowa " i komentarz 2 z numer 437 )

Uwaga: jak pokazano poniżej , częstą inną przyczyną problemu jest problem z prawami do katalogu (niewłaściwy właściciel), niekoniecznie do pliku, którego nie można odłączyć.

VonC
źródło
1
Jestem na Ubuntu, żeby to wyjaśnić. I niestety jestem tylko w tej przeglądarce internetowej i mojej konsoli, która ma jedną zakładkę otwartą do odpowiedniego katalogu (i dwie otwarte całkiem gdzie indziej).
Paragon
3
@Paragon: nawet na Uniksie możesz mieć problemy z obsługą. W przeciwnym razie powinna to być kwestia pozwolenia. Powinieneś być jednak w stanie wymusić kasę. git checkout -f master
VonC
2
+1 w moim przypadku było to współdzielenie folderów z aktywną maszyną wirtualną, które zabraniało odrzucania plików w git w systemie hosta. Doprowadziło mnie do szału, więc dzięki za podpowiedź!
Jook
1
Ten sam problem. Running Process Explorer> Ctrl + F> <filename> - wyświetli proces, który utrzymuje ten plik otwarty.
setevoy
1
GitExtensions wyświetlał ten błąd podczas próby pobrania wszystkich ... Miałem też otwarty GitKraken. Po zamknięciu GitKraken pobieranie działało bez błędów.
mkaj
99

W moim pierwszym spotkaniu z tym błędem mój użytkownik miał prawa do „zapisu” do pliku, ale nie do katalogu zawierającego. Sprawdź uprawnienia katalogu zawierającego plik.

Elijah Lynn
źródło
95
Ojej, zbyt zabawne, właśnie dzisiaj trafiłem na tę odpowiedź i zdałem sobie sprawę, że jest moja! Niemniej jednak zadziałało ponownie!
Elijah Lynn,
Ok, zdarzyło mi się to na Windows 10, przechodzę do głównego folderu projektu. i dodaj DLA WSZYSTKICH MOŻLIWYCH UŻYTKOWNIKÓW, wszystkie uprawnienia. A więc dla systemu, administratora, użytkowników, wszystkie możliwości. Zastosuj zmiany. I wydaje się, że działa, jakoś może przy aktualizacji Windows 10, nawet jeśli nie utworzymy nowego użytkownika, jesteśmy traktowani jak nowy, bez uprawnień. Na przykład mam dziwną nazwę S-1-15-32 ..... Nie jest to nazwa logowania, którą mam, kiedy odblokowujemy naszego laptopa.
PsychedelicSubstance
30

„Odłącz” zasadniczo oznacza w tym przypadku „usuń plik”.

Ten błąd nie jest spowodowany przez sam git. Powinieneś mieć podobne błędy, usuwając te pliki ręcznie, w wierszu poleceń lub eksploratorze plików.

rtconner
źródło
18
W moim pierwszym spotkaniu z tym błędem mój użytkownik miał uprawnienia do „zapisu” do pliku, ale katalog zawierający nie miał.
Elijah Lynn
3
@Elijah: Dziękuję! Tak właśnie było dla mnie.
Jesse Lee
4
W moim przypadku stwierdziłem, że plik, o którym mowa, został zablokowany przez inną aplikację. Zamknięcie aplikacji zwolniło plik i umożliwiło kontynuację wypisania.
Simon Tewsi
25

Nie masz uprawnień dostępu, być może dlatego, że nie jesteś właścicielem.

Napraw, zmieniając właściciela na siebie:

sudo chown -R your_login_name /path/to/folder
Vince Yuan
źródło
2
Na moim lokalnym komputerze deweloperskim wspomniane pliki zostały pierwotnie utworzone przez mój lokalny serwer Apache, więc były własnością użytkownika www-data. Kiedy już wyrzuciłem je na swoje konto, wszystko znów działało normalnie. Prawdziwym problemem była odmowa pozwolenia. „Nie można nie lubić” to tylko czerwony śledź.
Dale Anderson
23

Miałem problem z plikiem default-settings.php w drupal 7. W tym przypadku nie mogłem go usunąć ani przywrócić, tak jak powiedział @rtconner. Nie miałem aplikacji ani niczego, co używa tego pliku, a skończyło się to błędem uprawnień.

Dodałem chmod 777 *do folderu, a potem mogłem go przywrócić bez problemu.

Rob Erskine
źródło
3
Chociaż możesz nie chcieć, aby 777w żadnym folderze. To rozwiązało mój problem, ale szybko zmieniłem go z powrotem na domyślny po rozwiązaniu. Dzięki!
Bram
13

Aby to zrobić, możesz zmienić uprawnienia do zapisu.

sudo chmod -R ug+w . 

To polecenie nada 'w'uprawnienia do wszystkich folderów w bieżącym katalogu.

Rajendra kumar Vankadari
źródło
6

Natknąłem się na ten problem za każdym razem, gdy uruchamiałem „git repack” lub „git gc” na moich maszynach z systemem OS X, nawet podczas uruchamiania git z uprawnieniami administratora, i ostatecznie rozwiązałem go po przejściu na tę stronę: http://hints.macworld.com /comment.php?mode=view&cid=1734

Rozwiązaniem jest otwarcie terminala, przejście do repozytorium git, cd do folderu .git, a następnie:

chflags -R nouchg *

Jeśli to był problem, wtedy twoje polecenia git będą działać normalnie.

Naucz się OpenGL ES
źródło
1
Link do macworld jest już nieaktualny. Oto zaktualizowany ref: superuser.com/a/40754
webb
5

Może się to również zdarzyć, gdy:

  1. Uruchomiłeś proces w kontenerze Docker i:

  2. Niektóre pliki zostały wygenerowane przez ten proces i:

  3. Miejsce docelowe plików jest montowane jako wolumin na hoście platformy Docker i:

  4. Pracujesz gitna hoście Docker.


W takim przypadku przygotuj pliki, które chcesz zatwierdzić i uruchom:

git diff --name-only --cached | xargs ls -l 

Pliki spełniające powyższe kryteria będą miały przedrostek:

-rw-r--r-- 1 root root ...

Są własnością rooti nie można ich zapisywać, co nie jest dobre. Aby naprawić ten bieg:

 git diff --name-only --cached | xargs -i sh -c 'sudo chown $USER:$USER {}; chmod +w {}'

Czystszym rozwiązaniem byłoby prawdopodobnie użycie --useropcji, zobacz to dla Dockera i to dla Docker Compose .

davetapley
źródło
4

Tym, którzy używają Intellij , jak powiedział @rtconner, ten problem nie jest spowodowany przez git. Ponieważ IDE jest zablokowane, plik (i) git nie może go odłączyć. Musisz więc zamknąć swoje IDE, a następnie spróbować połączyć je (lub cokolwiek chcesz) za pomocą wiersza poleceń.

Hesam
źródło
To było to. Stało się wraz z programowaniem na Androida, ponieważ AndroidStudio to Intellij.
Reinherd
2

W moim przypadku był to znak „:” w nazwie folderu, który uniemożliwiał repozytorium git wyewidencjonowanie w systemie Windows.

simonC
źródło
2

na terminalu na Macu po prostu to robię

sudo git checkout. (żeby wszystko posprzątać)

i wtedy

sudo git pull origin

Jry
źródło
2

Miałem ten błąd na maszynie wirtualnej (z systemem Ubuntu), kiedy próbowałem to zrobić git reset --hard.

Poprawka polegała po prostu na uruchomieniu git reset --hardz komputera hosta OS X.

Henrik N
źródło
1

Żadna z innych sugestii nie zadziałała, ale to zadziałało:

sudo git reflog expire --expire=now --all && sudo git gc --prune=now --aggressive

0x1mason
źródło
1

W moim przypadku mój katalog Windows znajduje się w folderze Dropbox. Nie jest to kwestia specyficzna dla Git. Kiedy plik (w tym przypadku plik blokady) został właśnie utworzony, Dropbox potrzebuje kolejnej sekundy, aby przeprowadzić synchronizację. W tym czasie plik jest używany przez Dropbox i żaden program innej firmy (w tym przypadku Git) nie może go usunąć.

Moim rozwiązaniem jest zamknięcie Dropbox, a tym samym uniknięcie zakulisowej magii synchronizacji plików Dropbox.

Vincent
źródło
0

Mam napotkał ten błąd i jest to spowodowane złym „właściciela / grupy” w pliku / folderu . Musisz zwrócić się o pomoc do administratora serwera, aby zmienić „właściciela / grupę” tego pliku / folderu i spróbować ponownie, używając polecenia „git pull”. Lub jeśli jesteś sudoerem, po prostu sudo chown „Twoja nazwa właściciela / nazwa Twojej grupy” i spróbuj ponownie pobrać repozytorium. Spróbuj, na mnie działa w 100%!

Jeff Simons Decena
źródło
0

Upewnij się, że żadne skojarzone procesy lub wątki nie są uruchomione i w razie potrzeby zakończ zadanie lub wymuś zamknięcie.

Upewnij się, że zmieniłeś uprawnienia własności.

Creative_Cimmons
źródło
0

Ogólnie rzecz biorąc, jeśli dzieje się to w systemie Windows i używasz tortoisegit , jest to pamięć podręczna statusu tortoisegit . Zabij ten proces, a zostanie uwolniony.

WiseStrawberry
źródło
W rzeczywistości możesz całkowicie wyłączyć pamięć podręczną stanu TortoiseGit i ogólnie jest to coś, co bym polecił. Często jest to przyczyną wielu nieoczekiwanych blokad plików i sprawia, że ​​jest to o wiele większy problem, niż jest to warte. Po prostu użyj git statusz wiersza poleceń.
0

Po prostu musiałem przełączyć użytkownika z Ubuntu na moją rzeczywistą nazwę użytkownika, pod którą najpierw zrobiłem coś. To naprawiło.

Marc
źródło
a co z użytkownikami windowsa?
Herr Nentu '27
OP był na Ubuntu. Nie komentowałbym wątku Windows.
Marc
0

Rozwiązany dla mnie przez ustawienie mojego klienta git (GitExtensions) tak, aby zawsze działał w trybie administratora.

frodo2975
źródło
0

Miałem ten problem podczas korzystania z IntelliJ(14.1.3 Ultimate), chciałem cofnąć zmiany w jakimś pliku.

Rozwiązany przez zamknięcie Git Bashotwartego w innym oknie - kolejna próba przywrócenia IntelliJzadziałała.

Eel Lee
źródło
0

Napotkałem ten błąd i myślę, że problem polegał na tym, że uruchomiłem Eclipse i utworzyłem pliki jako administrator, dlatego były one własnością administratora (zauważone po uruchomieniu polecenia „ls -la” w folderze). Kiedy później próbowałem ukryć pliki, nie pozwalało mi to („nie można odłączyć plików” i tak dalej). Wykonanie chmod na plikach było rozwiązaniem dla mnie.

LConrad
źródło
0

Wszystko, co musisz zrobić, to podać uprawnienia, uruchomić poniższe polecenie z katalogu głównego projektu:

    chmod ug+w <directory path>
Hansa
źródło
0

Miałem ten sam problem, próbowałem kilku alternatyw, jak sugerowali inni.

Ale ostatecznie udzielenie poprawnych uprawnień do folderu .git rozwiązuje problemy.

sudo chown -R "${USER:-$(id -un)}" .git
Raza Rafaideen
źródło
0

W moim przypadku problem z uprawnieniami rozwiązany przez ustawienie www-datajako właściciel:

chown -R www-data project_folder_name
Avag Sargsyan
źródło
0

Myślę, że chodzi o twoje uprawnienia do pliku:

sudo chmod 777 -R <your-git-folder>
Johnny Cage
źródło