Permission denied znaczy, że systemowi zabrakło jednego konkretnego prawa - komunikat nie mówi którego. Zanim cokolwiek zmienisz, powtórz odrzuconą operację bez sudo, sprawdź tożsamość procesu poleceniem id i przejdź całą ścieżkę przez namei -l. Gdy zwykłe prawa niczego nie tłumaczą, zostają ACL, opcja noexec i SELinux.

Co naprawdę mówi ten komunikat?

Permission denied to tekstowa postać błędu EACCES: proces poprosił system o operację, a system odmówił, bo zabrakło potrzebnego prawa. Odmówić mogło prawo do samego pliku, prawo przejścia przez któryś katalog na ścieżce albo prawo wykonania programu. Komunikat jest ten sam we wszystkich trzech przypadkach - i dlatego sam w sobie niczego nie diagnozuje.

To nie to samo co HTTP 403 Forbidden. Permission denied przychodzi z systemu plików albo z procesu, 403 jest odpowiedzią serwera WWW, który żądanie zrozumiał i odmówił jego spełnienia. Oba potrafią wystąpić w jednym incydencie - odmowa systemowa w logu potrafi skończyć się 403 w przeglądarce - ale diagnozuje się je osobno. Odpowiedź HTTP prowadzi do diagnostyki kodu 403; tutaj zostajesz przy operacji lokalnej.

Skrypt działa u ciebie, pada w cronie

Zanim przejdziesz do komend, zobacz, jak ta odmowa wygląda w praktyce - bo prawie nigdy nie wygląda jak „plik ma złe prawa".

Napisałeś skrypt kopii zapasowej. Z terminala działa bez zarzutu, więc dodajesz go do crona i idziesz spać. Rano w logu stoi Permission denied, a kopia nie powstała. Uruchamiasz skrypt ręcznie jeszcze raz - działa. Różnica nie siedzi w skrypcie, tylko w tożsamości: z terminala uruchamiasz go jako siebie, cron uruchomił go jako innego użytkownika, który do katalogu z danymi nie ma prawa wejść.

Druga wersja tej samej pułapki: strona nie zapisuje plików do katalogu uploads. Wchodzisz na serwer, sprawdzasz - katalog istnieje, prawa wyglądają rozsądnie, zapis z twojej powłoki działa. Tyle że stronę obsługuje proces serwera WWW, nie ty. On należy do innego użytkownika i innej grupy, a jego prawa sprawdziłeś dopiero wtedy, gdy przestałeś testować własne.

W obu historiach naprawianie „pliku, który nie działa" prowadzi donikąd, bo odmowa nie dotyczyła pliku - dotyczyła podmiotu. Dlatego diagnoza zaczyna się od pytania, komu odmówiono, a nie co poprawić.

Powtórz dokładnie to, co się nie udało

Powtórz dokładnie tę operację, która została odrzucona - ta sama komenda, ta sama pełna ścieżka, ten sam użytkownik albo proces. I bez sudo, bo z sudo sprawdzisz uprawnienia roota, a nie te, które właśnie odmówiły.

Zanotuj sobie przy tym pięć rzeczy - będą ci potrzebne w każdym kolejnym kroku:

  1. jaka to operacja: odczyt, zapis, przejście przez katalog czy uruchomienie;
  2. pełna ścieżka do zasobu;
  3. kto ją wykonywał - ty, inny użytkownik czy proces usługi;
  4. skąd - powłoka, cron, kontener, środowisko usługi;
  5. kiedy dokładnie, ze strefą czasową - przyda się przy przeszukiwaniu logów.

Każda operacja wymaga innego prawa. Odczyt to co innego niż zapis, a wejście do katalogu to co innego niż wylistowanie jego zawartości. Dopóki nie nazwiesz operacji, nie wiesz nawet, którego prawa szukasz.

Sprawdź, kim jest proces, któremu odmówiono

W tej samej powłoce, w której wystąpiła odmowa, uruchom:

id

Dostaniesz realny i efektywny identyfikator użytkownika oraz listę grup. To na tej podstawie system wybiera, którą klasą praw cię potraktuje: prawami właściciela pliku, jego grupy czy pozostałych użytkowników.

Jeśli błąd zgłasza usługa albo cron, wynik id z twojego terminala opisuje ciebie, nie ją. Podmiot usługi znajdziesz w jej konfiguracji albo w menedżerze usług - i dopiero jego użytkownik z jego grupami jest właściwym wejściem do dalszej kontroli. To jest dokładnie ten krok, którego zabrakło w obu historiach wyżej.

Znajdź katalog, który blokuje ścieżkę

Żeby dostać się do pliku, proces musi przejść przez każdy katalog na ścieżce. Brak prawa wyszukiwania na jednym z nich wystarczy do EACCES - nawet gdy końcowy plik ma prawa idealne. Zamiast zgadywać, który katalog blokuje, obejrzyj całą ścieżkę naraz:

namei -l /SCIEZKA/DO/ZASOBU

W miejsce /SCIEZKA/DO/ZASOBU wstaw pełną ścieżkę badanego pliku albo katalogu. Dostaniesz listę wszystkich elementów ścieżki z trybem, właścicielem i grupą każdego z nich.

Czytaj wynik od początku i porównuj z tożsamością z poprzedniego kroku. Przy katalogu x oznacza prawo wejścia i wyszukiwania, r pozwala wylistować zawartość. Przy pliku r to odczyt, w zapis, x wykonanie. Pierwszy element, na którym twojemu podmiotowi brakuje potrzebnego prawa, to punkt odmowy.

namei pokazuje tylko klasyczne bity trybu. Jeśli wszystko się zgadza, a odmowa zostaje, blokuje któryś z mechanizmów opisanych niżej.

Gdzie szukać dalej - tabela decyzji

Poniższa tabela prowadzi od operacji do mechanizmu, który mógł odmówić. Każdy wiersz kończy się testem tylko do odczytu - żaden niczego jeszcze nie zmienia.

Co się nie udało Gdzie szukać odmowy Mechanizm Test
odczyt albo zapis pliku końcowy plik bity trybu porównaj operację z trybem pliku w namei -l
dostęp do zasobu pod ścieżką katalog nadrzędny brak prawa wyszukiwania znajdź w namei -l pierwszy katalog bez x dla twojego podmiotu
odmowa mimo zgodnych bitów plik albo katalog ACL i jej maska getfacl na wskazanym zasobie
uruchomienie pliku zamontowany system plików opcja noexec findmnt --target dla ścieżki pliku
odmowa przy aktywnym SELinux obiekt z rekordu AVC polityka SELinux ausearch po logu audytu

Ten sam objaw potrafi prowadzić do różnych mechanizmów zależnie od operacji i podmiotu. Dopiero wynik testu mówi, co wolno korygować - tabela nie zastępuje testu.

Prawa wyglądają dobrze, a odmowa zostaje?

ACL - prawa, których nie widać w ls

ACL to lista kontroli dostępu: rozszerza klasyczne prawa o wpisy dla konkretnych, nazwanych użytkowników i grup. Ma też maskę, która potrafi przyciąć prawa efektywne - tryb pliku wygląda wtedy poprawnie, a dostęp i tak nie przechodzi. Odczytaj ją:

getfacl /SCIEZKA/DO/ZASOBU

Znajdź wpis dotyczący twojego użytkownika albo jego grupy i sprawdź prawa efektywne po zastosowaniu maski. Samo istnienie ACL niczego nie przesądza - dowodem jest dopiero wpis, który realnie ogranicza twój podmiot. Gdy system plików ACL nie obsługuje, wynik odpowiada zwykłym bitom trybu i ten trop możesz zamknąć.

noexec - system plików bez prawa wykonania

Przy próbie uruchomienia pliku EACCES może przyjść nie od praw pliku, tylko od opcji montowania: system plików zamontowany z noexec nie wykona niczego, niezależnie od bitów x. Dotyczy to wyłącznie bezpośredniego wykonania - odmowy odczytu ani zapisu ta opcja nie tłumaczy. Sprawdź, na czym leży plik:

findmnt --target /SCIEZKA/DO/ZASOBU --output TARGET,VFS-OPTIONS,FS-OPTIONS

W wyniku zobaczysz punkt montowania i jego opcje. Jeśli jest wśród nich noexec, znalazłeś punkt odmowy - i żadna zmiana praw pliku go nie obejdzie.

SELinux - polityka ponad prawami

Przy aktywnym SELinux zgodne bity trybu i czysta ACL nie kończą kontroli: ostatnie słowo ma polityka, a jej odmowy lądują w logu audytu jako rekordy AVC. Wyszukaj je z uprawnieniem do odczytu tego logu:

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

recent to krótkie okno liczone wstecz od uruchomienia komendy, nie od początku twojej diagnozy - dlatego odpal ją zaraz po powtórzeniu odmowy i zachowaj wynik. W pasującym rekordzie odczytasz odmówioną akcję, proces oraz konteksty bezpieczeństwa podmiotu i celu.

Brak rekordu niczego nie rozstrzyga w żadną stronę. Nie wyłączaj polityki i nie generuj reguł na podstawie samego komunikatu - podstawą korekty jest rekord powiązany z twoją operacją, nie przypuszczenie.

Dlaczego chmod 777 nie jest naprawą?

Bo niczego nie diagnozuje, a otwiera wszystko. Tryb liczbowy to zapis ósemkowy: trzy cyfry opisują kolejno właściciela, grupę i pozostałych, a w każdej cyfrze odczyt ma wartość 4, zapis 2, wykonanie lub wyszukiwanie 1. 777 daje więc pełne rwx wszystkim - również tym, którym nigdy nie powinieneś go dawać.

Po takiej zmianie nadal nie wiesz, gdzie była odmowa. Maski ACL, opcji noexec ani decyzji SELinux 777 nie rusza - więc jeśli blokował któryś z nich, problem zostaje, tylko teraz z otwartym na oścież plikiem. Tryby 755 (właściciel rwx, reszta rx) i 644 (właściciel rw, reszta r) to konkretne, przemyślane podziały praw, nie uniwersalne zaklęcia na każdy komunikat o odmowie.

Gdy diagnoza potwierdzi, że winne są bity trybu albo właściciel, przejdź do instrukcji zmiany właściciela i praw plików - tam jest sama korekta. Ta strona kończy się na wskazaniu mechanizmu i minimalnego zakresu zmiany.

Jak sprawdzisz, że naprawiłeś właściwą rzecz?

Po korekcie powtórz dokładnie tę samą operację jako ten sam podmiot - skrypt z crona testuj przez crona, zapis strony przez proces serwera, nie przez własną powłokę. Zgodny wynik potwierdza dostęp do tego zasobu dla tego podmiotu i niczego więcej; nie rozciągaj wniosku na inne pliki ani konta.

Zrób też kontrolę odwrotną i sprawdź, czy podmiot, który dostępu mieć nie powinien, nadal jest odrzucany. Jeśli po twojej zmianie do katalogu z kopiami zapasowymi może pisać każdy, to nie była naprawa - to była kapitulacja.

Pytania o Permission denied

Co oznacza Permission denied?

Permission denied to komunikat błędu EACCES: proces nie dostał prawa potrzebnego do konkretnej operacji. Odmowa mogła paść przy odczycie, zapisie, przejściu przez katalog albo uruchomieniu programu. Sam komunikat nie mówi, czy zablokowały bity trybu, ACL, opcja noexec czy polityka SELinux - to trzeba ustalić testami.

Jak naprawić Permission denied w Linux?

Powtórz odrzuconą operację bez sudo, sprawdź tożsamość procesu poleceniem id i przejdź całą ścieżkę przez namei -l. Gdy bity trybu niczego nie tłumaczą, odczytaj ACL przez getfacl, opcje montowania przez findmnt i rekordy AVC przez ausearch. Prawa zmieniaj dopiero po wskazaniu mechanizmu i punktu odmowy.

Dlaczego nie zaczynać od chmod 777?

Bo 777 daje odczyt, zapis i wykonanie wszystkim użytkownikom, a nie wskazuje, gdzie była odmowa. Nie usuwa też ograniczeń maski ACL, opcji noexec ani decyzji SELinux - jeśli blokował któryś z nich, odmowa zostaje, a plik jest już otwarty dla każdego. Najpierw ustal podmiot i mechanizm, potem zmień tylko potwierdzony zakres.

Co oznaczają tryby 755 i 644?

Tryb 755 daje właścicielowi pełne rwx, a grupie i pozostałym rx - typowy dla katalogów i programów. Tryb 644 daje właścicielowi rw, reszcie sam odczyt - typowy dla zwykłych plików. Właściwy tryb wynika z tego, kto ma wykonywać jaką operację, nie z samego komunikatu o odmowie.

Dlaczego plik ma dobre prawa, a dostęp dalej jest odrzucany?

Blokuje wtedy coś innego niż końcowy plik. System sprawdza prawo wyszukiwania na każdym katalogu ścieżki, dostęp potrafi przyciąć maska ACL, wykonanie zatrzymuje opcja noexec, a przy aktywnym SELinux ostatnie słowo ma polityka. Każdy z tych mechanizmów ma własny test tylko do odczytu - przejdź je po kolei.

Czy Permission denied i 403 Forbidden to to samo?

Nie. Permission denied to błąd systemowy przy dostępie do pliku, katalogu albo przy uruchamianiu procesu. 403 Forbidden to status HTTP: serwer zrozumiał żądanie i odmówił jego spełnienia. Odmowa systemowa bywa przyczyną 403 na stronie, ale diagnozuje się je osobno - dla HTTP właściwa jest diagnostyka kodu 403.

Co oznacza Permission denied (publickey)?

Dopisek publickey wskazuje metodę uwierzytelniania OpenSSH - to odmowa logowania SSH, nie odmowa dostępu do pliku na dysku. Naprawia się ją po stronie kluczy i konfiguracji SSH, a nie zmianą praw badanego pliku - dalej prowadzi procedura połączenia i diagnostyki SSH.

Dokąd stąd dalej

Ta strona prowadzi od komunikatu Permission denied do mechanizmu, który odmówił - przy pliku, katalogu albo uruchamianym procesie. Samą zmianę właściciela i praw opisuje instrukcja chmod i chown, odpowiedź HTTP diagnostyka kodu 403, a pozostałe komunikaty odmowy dostępu zbiera przegląd błędów dostępu.

Fakty w tej instrukcji pochodzą z dokumentacji - Linux man-pages: path_resolution(7), execve(2), getfacl(1); GNU Coreutils: Mode Structure, Numeric Modes, id, chmod; util-linux: namei(1), findmnt(8), mount(8); dokumentacja Red Hat Enterprise Linux o SELinux; RFC 9110, sekcja 15.5.4; OpenBSD manual pages: sshd_config(5).