Jak naprawić błędy uprawnień w Linux: chmod, chown i ACL

Dlaczego w ogóle pojawiają się błędy uprawnień w Linux

Typowe komunikaty błędów związane z uprawnieniami

Błędy uprawnień w Linux objawiają się kilkoma powtarzającymi się komunikatami. Znajomość ich treści bardzo ułatwia diagnozę. Najczęstsze z nich to:

• Permission denied – brak dostępu do pliku lub katalogu (odczyt, zapis albo wykonanie).
• Operation not permitted – operacja jest zabroniona nawet dla bieżącego użytkownika, często wynika z braku uprawnień roota (UID 0) lub z ograniczeń nałożonych atrybutami plików.
• Read-only file system – system plików jest zamontowany tylko do odczytu, zmiana uprawnień nic nie da, dopóki nie zmienisz sposobu montowania.
• Access denied przy próbie montowania zasobów sieciowych (Samba, NFS) – problem może leżeć zarówno po stronie Linuxa, jak i serwera.

Zanim zaczniesz modyfikować prawa chmod, własność chown czy ACL, dobrze jest dokładnie przeczytać komunikat błędu, bo często podpowiada, czy problem dotyczy samego pliku, katalogu nadrzędnego, czy całego systemu plików.

Najczęstsze przyczyny problemów z uprawnieniami

Chaotyczne używanie chmod i chown, szybkie kopiowanie danych między użytkownikami, odtwarzanie backupów bez zachowania metadanych – to typowe sytuacje, w których prawa dostępu zaczynają się „rozjeżdżać”. Do tego dochodzą:

• instalacja oprogramowania spoza repozytoriów i ręczne nadawanie uprawnień,
• zmiany w konfiguracji serwerów WWW (Apache, Nginx) i aplikacji webowych,
• skrypty deployujące, które korzystają z nieoptymalnych komend typu chmod -R 777,
• użytkownicy modyfikujący katalogi domowe innych osób lub katalogi współdzielone,
• przenoszenie danych między różnymi systemami plików (ext4 <-> NTFS, CIFS, NFS itp.) bez zachowania UID/GID.

W większości przypadków naprawa błędów uprawnień w Linux wymaga zrozumienia trzech elementów: klasycznych bitów dostępu (chmod), własności plików (chown) oraz rozszerzonych list kontroli dostępu (ACL). Ignorowanie któregoś z nich powoduje, że problemy wracają jak bumerang.

Model bezpieczeństwa Linux w skrócie

Podstawowy model bezpieczeństwa Linux opiera się na trzech filarach:

• Użytkownik (owner, UID) – pojedyncze konto, które jest właścicielem pliku.
• Grupa (group, GID) – grupa, której członkowie mogą mieć wspólne prawa do plików.
• Inni (others) – wszyscy pozostali użytkownicy systemu.

Do tego dochodzą trzy podstawowe operacje: read (r), write (w), execute (x), a także bity specjalne (SUID, SGID, sticky). Na tych fundamentach opierają się zarówno komendy chmod i chown, jak i rozszerzone uprawnienia ACL. Zrozumienie, kto jest kim i jakie ma uprawnienia, to pierwszy krok do skutecznej naprawy błędów uprawnień.

Jak analizować uprawnienia plików i katalogów

Odczytywanie wyniku polecenia ls -l

Najprostszym narzędziem do analizy praw jest ls -l. Przykład:

$ ls -l /var/www/html/index.php
-rw-r----- 1 www-data www-data 12345 sty  5 12:34 /var/www/html/index.php

Ten wynik można „rozebrać” na czynniki pierwsze:

• - – typ pliku (myślnik = zwykły plik, d = katalog, l = dowiązanie symboliczne).
• rw-r----- – dziewięć znaków opisujących uprawnienia: właściciel, grupa, inni.
• 1 – liczba dowiązań (linków) do pliku.
• www-data – właściciel (użytkownik).
• www-data – grupa.
• 12345 – rozmiar pliku.
• data i godzina modyfikacji oraz ścieżka pliku.

Sekwencję uprawnień rw-r----- można podzielić na trzy części:

• rw- – właściciel: czytanie + zapis, brak wykonywania,
• r-- – grupa: tylko czytanie,
• --- – inni: brak uprawnień.

Jak rozumieć uprawnienia do katalogów

Przy katalogach bity uprawnień mają delikatnie inne znaczenie niż przy zwykłych plikach:

• r – możliwość odczytania listy plików (ls).
• w – możliwość tworzenia i usuwania plików w katalogu.
• x – możliwość wejścia do katalogu (cd) i dostępu do plików po nazwie.

Klasyczny przykład błędu: katalog ma uprawnienia r-- bez x. Użytkownik widzi listę plików, ale nie może wejść do katalogu ani otworzyć konkretnego pliku. Naprawa polega na dodaniu bitu x:

chmod u+x /sciezka/do/katalogu

W kontekście błędów typu „Permission denied” przy wejściu do katalogu, brak x jest jednym z najczęstszych powodów. Dotyczy to nie tylko samego katalogu, ale całej ścieżki – jeśli którykolwiek katalog nadrzędny nie ma odpowiedniego bitu x, dostęp zostanie zablokowany.

Sprawdzanie właściciela i grupy pliku

Dla prawidłowego działania usług niezwykle istotne jest, który użytkownik i która grupa są właścicielami plików. Przykładowo:

• Pliki serwera WWW często powinny należeć do użytkownika i grupy www-data (Debian/Ubuntu) lub apache/nginx (CentOS/RHEL).
• Pliki użytkowników muszą być własnością konkretnego konta z katalogu /home.
• Logi systemowe zwykle należą do root lub dedykowanych użytkowników usług.

Do sprawdzenia właściciela i grupy w szerszym zakresie można użyć:

find /var/www -maxdepth 2 -ls

Flagą, która często pomaga przy diagnozowaniu, jest -Z przy SELinux, ale przy klasycznych błędach uprawnień w Linux najczęściej wystarcza zwykłe ls -l i find z opcją wyświetlania metadanych.

Naprawa błędów uprawnień za pomocą chmod

Składnia chmod: tryb symboliczny i ósemkowy

Komenda chmod zmienia prawa do plików i katalogów. Ma dwie główne formy zapisu:

• symboliczny – np. chmod u+rwx,g+rx,o-r
• ósemkowy – np. chmod 750 plik

Tryb symboliczny pozwala dodawać lub odejmować konkretne uprawnienia względem stanu bieżącego. Kilka typowych przykładów naprawy:

• chmod u+x skrypt.sh – dodanie prawa wykonania dla właściciela, gdy pojawia się błąd „Permission denied” przy próbie uruchomienia skryptu.
• chmod go-rw plik.txt – odebranie prawa odczytu i zapisu grupie i innym.
• chmod a+r dokument.pdf – nadanie prawa odczytu wszystkim, przydatne przy współdzieleniu plików.

Tryb ósemkowy opiera się na sumie bitów: r=4, w=2, x=1. Każda cyfra reprezentuje uprawnienia odpowiednio dla właściciela, grupy i innych. Przykładowo:

• 7 = 4+2+1 = rwx
• 5 = 4+1 = r-x
• 6 = 4+2 = rw-

Przykładowa naprawa:

chmod 640 /etc/aplikacja/sekret.conf

Właściciel może czytać i pisać, grupa tylko czytać, inni nie mają żadnego dostępu. To bardzo typowy schemat dla plików konfiguracyjnych z hasłami lub tokenami.

Uprawnienia domyślne i umask – ukryty sprawca niektórych problemów

Część błędów uprawnień wynika nie z późniejszych zmian, ale z tego, jak pliki zostały utworzone. Tutaj w grę wchodzi mechanizm umask, który określa, jakie bity uprawnień zostaną „zgaszone” przy tworzeniu nowego pliku lub katalogu.

Sprawdzenie aktualnej wartości:

$ umask
0022

Umask 0022 oznacza, że:

• dla katalogów bazą jest 777, więc wynikowe prawa to 755 (rwxr-xr-x),
• dla plików bazą jest 666, więc wynikowe prawa to 644 (rw-r–r–).

Jeśli użytkownicy skarżą się, że nowo tworzone pliki nie są dostępne dla innych w katalogu współdzielonym, często wystarczy zmiana umask, np. w /etc/profile lub plikach powłoki użytkownika:

umask 0002

Dzięki temu nowo tworzone pliki będą miały uprawnienia 664 (rw-rw-r–) i będą dostępne do zapisu również dla grupy.

Rekurencyjne chmod i typowe pułapki

Naprawiając błędy uprawnień w drzewie katalogów, wiele osób sięga po chmod -R. To potężne, ale niebezpieczne narzędzie. Bezrefleksyjne:

chmod -R 777 /var/www

robi dwie rzeczy jednocześnie:

• otwiera pliki i katalogi na oścież dla wszystkich (ogromne ryzyko bezpieczeństwa),
• nadaje bit wykonywalności również zwykłym plikom, które nie powinny być wykonywalne.

Bezpieczniej jest rozdzielić ustawienia dla katalogów i dla plików, np. w strukturze strony WWW:

# katalogi: 755 (rwxr-xr-x)
find /var/www/html -type d -exec chmod 755 {} ;

# pliki: 644 (rw-r--r--)
find /var/www/html -type f -exec chmod 644 {} ;

Można też ograniczyć się do konkretnych ścieżek, zamiast stosować -R zbyt szeroko. Przy dużych projektach dobrze jest najpierw wykonać suchy przebieg z -print, sprawdzając, które pliki zostaną zmienione:

find /var/www/html -type d -print

Przywracanie poprawnych uprawnień po błędach użytkownika

Klasyczny scenariusz z praktyki: ktoś wykonał w katalogu domowym:

chmod -R 777 ~

i nagle część aplikacji zaczęła zachowywać się dziwnie, a system loguje ostrzeżenia. W takich sytuacjach nie ma jednego uniwersalnego polecenia naprawczego, ale można działać etapami:

1. Ustalić, które katalogi mają specyficzne wymagania (np. .ssh, .gnupg, katalogi konfiguracyjne).
2. Dla katalogu .ssh zastosować:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/id_rsa
   chmod 644 ~/.ssh/id_rsa.pub ~/.ssh/known_hosts
           

3. Dla reszty katalogów i plików przyjąć rozsądne domyślne wartości:

   find ~ -type d -exec chmod 755 {} ;
   find ~ -type f -exec chmod 644 {} ;
           

Podobnie postępuje się przy naprawie uprawnień katalogów aplikacji – zaczyna się od krytycznych plików (klucze, hasła), potem ustawia domyślne prawa dla reszty, trzymając się dobrych praktyk bezpieczeństwa.

Zarządzanie własnością plików za pomocą chown

Podstawy chown: użytkownik, grupa i dziedziczenie

Komenda chown zmienia właściciela i grupę pliku lub katalogu. Składnia:

chown [OPCJE] UŻYTKOWNIK[:GRUPA] PLIK...

Przykłady typowych napraw:

• chown www-data:www-data /var/www/html/index.php – ustawienie właściciela i grupy na użytkownika serwera WWW.
• chown user1: /home/user1/plik.txt – zmiana tylko właściciela, grupa pozostaje bez zmian.
• chown :developers /projekty/app – zmiana tylko grupy na developers.

Rekurencyjne chown i naprawa całych drzew katalogów

Podobnie jak przy chmod, również chown ma opcję rekurencyjną -R. Przydaje się, gdy aplikacja została przeniesiona lub rozpakowana jako root i wszystkie pliki mają nieprawidłowego właściciela:

# katalog projektu ma należeć do użytkownika appuser i grupy appgroup
chown -R appuser:appgroup /opt/aplikacja

Przy usługach sieciowych typowym krokiem naprawczym jest ustawienie właściciela na użytkownika procesu serwera:

# naprawa uprawnień dla plików WWW
chown -R www-data:www-data /var/www/html

Warto używać rekurencji precyzyjnie – tylko na wybranych katalogach aplikacji, nie na całych systemowych drzewach jak /etc czy /usr. Jedna pomyłka we własności plików systemowych może unieruchomić logowanie, sudo lub menedżer pakietów.

Diagnostyka błędów „Permission denied” związanych z właścicielem

Gdy proces zgłasza „Permission denied”, a uprawnienia rwx wyglądają poprawnie, często problemem jest niewłaściwy właściciel lub grupa. Dobrze sprawdzają się trzy szybkie kroki:

1. Ustalić, pod jakim użytkownikiem faktycznie działa proces:

   ps aux | grep nginx
   ps aux | grep postgres
           

2. Zweryfikować właściciela i grupę problematycznego pliku:

   ls -l /sciezka/do/pliku_lub_katalogu
           

3. Porównać grupy użytkownika:

   id NAZWA_UZYTKOWNIKA
           

Jeśli proces działa jako www-data, a pliki należą do root:root i mają uprawnienia 640, serwer WWW nie będzie ich czytał. Naprawa:

chown -R www-data:www-data /var/www/projekt
# ewentualnie tylko grupę, jeśli właścicielem ma pozostać deweloper
chown -R :www-data /var/www/projekt
chmod -R g+rX /var/www/projekt

setgid na katalogu – automatyczne dziedziczenie grupy

W katalogach współdzielonych problemem jest spójne przypisywanie grupy do nowych plików. Można to rozwiązać bitem setgid na katalogu:

# katalog współdzielony przez grupę developers
mkdir -p /projekty/app
chown root:developers /projekty/app
chmod 2775 /projekty/app

Cyfra 2 na pierwszej pozycji (2775) ustawia bit setgid na katalogu. Efekty:

• nowe pliki i katalogi tworzone w środku dziedziczą grupę katalogu nadrzędnego (developers),
• łatwiej utrzymać poprawną grupę bez ręcznego chown po każdym deployu.

Dla istniejącej struktury:

chmod g+s /projekty/app

Najczęstsze pomyłki z chown i ich skutki

Kilka błędów, które często prowadzą do trudnych do namierzenia problemów:

• chown na całe /home – zmiana własności katalogów innych użytkowników może zablokować logowanie lub dostęp do ich plików.
• chown na /var/lib bazy danych – np. przypadkowe ustawienie root:root na danych PostgreSQL czy MySQL kończy się błędami przy starcie usługi.
• mieszanie użytkowników systemowych z ludzkimi – nadawanie właściciela root plikom tworzonym regularnie przez zwykłych użytkowników generuje ciągłe błędy i konieczność używania sudo do wszystkiego.

Jeżeli dojdzie do takiej pomyłki, często jedynym sensownym rozwiązaniem bywa przywrócenie kopii zapasowej lub porównanie z drugim, poprawnie skonfigurowanym systemem, żeby ustalić oczekiwane właścicielstwo najważniejszych katalogów.

Zaawansowane uprawnienia: ACL (Access Control Lists)

Dlaczego standardowe rwx czasem nie wystarcza

Klasyczny model u/g/o bywa zbyt sztywny – można przypisać dokładnie jednego właściciela, jedną grupę oraz uprawnienia dla wszystkich pozostałych. W praktyce potrzebne są często scenariusze typu:

• konkretny użytkownik z innej grupy ma mieć dodatkowy dostęp tylko do jednego katalogu,
• dwie grupy mają współdzielić ten sam zbiór plików z różnymi poziomami dostępu,
• potrzebna jest precyzyjna kontrola, kto może wykonywać plik, a kto tylko go czytać.

Do takich przypadków służą listy kontroli dostępu – ACL, obsługiwane przez narzędzia setfacl i getfacl.

Włączanie obsługi ACL w systemie plików

Większość dystrybucji ma ACL włączone domyślnie, ale jeśli komendy nie działają zgodnie z oczekiwaniami, trzeba sprawdzić opcje montowania:

mount | grep ' /home '

W wynikach powinna być opcja acl. Jeżeli jej brakuje, w /etc/fstab można dopisać:

UUID=...  /home  ext4  defaults,acl  0  2

Po zmianie montujemy ponownie system plików lub restartujemy system:

mount -o remount /home

Podstawy setfacl i getfacl

Dwa kluczowe polecenia przy pracy z ACL:

• getfacl PLIK – wyświetla aktualne ACL,
• setfacl [opcje] PLIK – ustawia lub modyfikuje reguły.

Przykład: dodatkowy dostęp odczytu dla użytkownika anna do pliku, którego grupa i właściciel nie powinny być zmieniane:

setfacl -m u:anna:r /sekretne/raport.txt
getfacl /sekretne/raport.txt

Przykładowy wynik getfacl:

# file: raport.txt
# owner: root
# group: finanse
user::rw-
user:anna:r--
group::---
mask::r--
other::---

Widać, że oprócz standardowych wpisów user::, group::, other:: pojawił się wpis specyficzny dla użytkownika anna.

Maska ACL i niespodziewane „Permission denied”

Elementem, który często myli administratorów, jest mask. Określa ona maksymalne efektywne uprawnienia dla wszystkich wpisów innych niż właściciel pliku (dodatkowych użytkowników i grup oraz grupy głównej).

Jeśli dla pliku ustawiono:

user:anna:rwx
mask::r--

to anna efektywnie ma tylko r--, nawet jeśli wpis ACL mówi rwx. Podstawowy sposób aktualizacji maski, gdy dokładamy nowe uprawnienia:

setfacl -m u:anna:rw /katalog/dane.txt
setfacl -m m::rw /katalog/dane.txt

lub jednocześnie:

setfacl -m u:anna:rw,m::rw /katalog/dane.txt

Dziedziczenie ACL w katalogach

ACL mogą być dziedziczone przez pliki i katalogi tworzone wewnątrz danego katalogu. Służą do tego wpisy typu default: (oznaczane literą d):

# katalog współdzielony
mkdir /dane/wspolne
chown root:projekt /dane/wspolne
chmod 2770 /dane/wspolne

# wszyscy z grupy projekt mają pełny dostęp
setfacl -m g:projekt:rwx /dane/wspolne
setfacl -m d:g:projekt:rwx /dane/wspolne

Dzięki wpisowi default nowe pliki tworzone w /dane/wspolne odziedziczą ACL, więc członkowie grupy projekt zachowają odczyt i zapis, nawet jeśli domyślna umask użytkownika byłaby bardziej restrykcyjna.

ACL a rekurencyjne operacje chmod i chown

Standardowy chmod modyfikuje również podstawowe wpisy ACL (user::, group::, other::), ale dodatkowe wpisy użytkowników i grup pozostają. To czasem prowadzi do niejasnych sytuacji: ktoś zmienia uprawnienia na 640, ale inny użytkownik nadal ma dostęp przez ACL.

Aby całkowicie „wyczyścić” ACL przy naprawie:

# usunięcie wszystkich ACL z pliku
setfacl -b plik.txt

# usunięcie ACL rekurencyjnie z katalogu
setfacl -Rb /dane/wspolne

Jeśli celem jest przywrócenie klasycznego modelu uprawnień bez dodatkowych wyjątków, taka operacja jest często konieczna przed ustawieniem nowych praw za pomocą chmod i chown.

Przykład: katalog projektu z mieszanym dostępem

Realny scenariusz: repozytorium projektu w /srv/projekty/app1, do którego:

• deweloperzy mają pełny dostęp (czytanie, zapis, usuwanie),
• użytkownik qa ma dostęp tylko do odczytu,
• serwer CI (ci-runner) ma prawo wykonania kilku skryptów.

Możliwe rozwiązanie:

# własność katalogu
chown -R leaddev:devs /srv/projekty/app1
chmod 2770 /srv/projekty/app1

# ACL: pełny dostęp dla grupy devs
setfacl -R -m g:devs:rwx /srv/projekty/app1
setfacl -R -m d:g:devs:rwx /srv/projekty/app1

# użytkownik qa: tylko odczyt
setfacl -R -m u:qa:rX /srv/projekty/app1
setfacl -R -m d:u:qa:rX /srv/projekty/app1

# użytkownik ci-runner: dodatkowe wykonanie tylko na skryptach build
setfacl -m u:ci-runner:rx /srv/projekty/app1/scripts/build.sh

Taki układ pozwala naprawić konflikty, gdy standardowe rwx wymuszałoby zbyt szeroki dostęp dla całej grupy lub wszystkich innych użytkowników.

Zaawansowane bity uprawnień: SUID, SGID i sticky

SUID i SGID na plikach wykonywalnych

Bity SUID (4) i SGID (2) dla plików wykonywalnych zmieniają sposób, w jaki proces dziedziczy tożsamość. Ustawiamy je ósemkowo jako dodatkową cyfrę z przodu:

• SUID (4xxx) – program uruchomiony przez użytkownika działa z uprawnieniami właściciela pliku,
• SGID (2xxx) – program działa z grupą pliku jako efektywną grupą.

Przykład (nie ustawiaj tego w produkcji bez bardzo dobrego powodu):

# teoretycznie: użytkownik może zmieniać hasło, choć plik shadow jest własnością root
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ...

Litera s w miejscu x oznacza aktywny SUID. Bezpośrednie używanie SUID/SGID jako „naprawy” błędów uprawnień w aplikacjach użytkownika jest z reguły złą praktyką – utrudnia audyt i zwiększa powierzchnię ataku.

Sticky bit na katalogach współdzielonych

Sticky bit (1xxx) stosowany na katalogach chroni pliki przed usuwaniem przez innych użytkowników, mimo że mają oni prawo zapisu do katalogu. Klasyczny przykład:

ls -ld /tmp
drwxrwxrwt 10 root root ...

Litera t na końcu oznacza sticky bit. Dzięki temu:

• każdy użytkownik może tworzyć pliki w /tmp,
• ale plik może usunąć tylko jego właściciel lub root.

Jeśli katalog roboczy jest współdzielony i użytkownicy przypadkiem kasują sobie nawzajem pliki, rozwiązaniem jest:

chmod 1777 /dane/wspolne/tmp

Naprawa błędów spowodowanych utratą specjalnych bitów

Czasami agresywne użycie chmod -R usuwa SUID/SGID lub sticky bit z kluczowych plików lub katalogów, co kończy się dziwnymi błędami (np. brak możliwości zmiany hasła, problemy z pocztą). Przykładowe przywrócenie:

# /usr/bin/passwd powinien mieć SUID
chmod u+s /usr/bin/passwd

# katalog /tmp powinien mieć sticky bit
chmod 1777 /tmp

Jeśli istnieje podejrzenie, że wiele plików systemowych straciło swoje specjalne bity, lepiej użyć narzędzi dystrybucji (np. rpm --setperms na RHEL/CentOS, dpkg --get-selections + dpkg-reconfigure na Debian/Ubuntu) lub porównać z listą plików w pakietach.

Praktyczne schematy naprawy błędów uprawnień

Serwer WWW: typowe prawa i naprawa problemów z uploadem

Najczęstszy przypadek w administracji – użytkownicy widzą stronę, ale nie mogą wgrywać plików albo aplikacja PHP zgłasza błąd „Permission denied” przy zapisie w katalogu uploads.

Są trzy elementy do weryfikacji:

• jaki użytkownik i grupa uruchamiają proces serwera WWW (np. www-data, apache, nginx),
• kto jest właścicielem plików aplikacji,
• jakie uprawnienia ma katalog do zapisu (upload, cache, logi aplikacji).

Szybkie sprawdzenie użytkownika procesu:

ps aux | egrep 'apache2|httpd|nginx' | head

W typowej konfiguracji aplikacja jest własnością dewelopera lub technicznego użytkownika, np. appuser:appgroup, a serwer WWW to www-data. Do bezpiecznego uploadu potrzebny jest katalog, w którym www-data ma prawo zapisu, ale nie musi być właścicielem całego drzewa:

# katalog na upload
mkdir /var/www/app/uploads
chown appuser:appgroup /var/www/app/uploads

# dodajemy www-data do grupy appgroup
usermod -aG appgroup www-data

# prawa dla katalogu (z bitem SGID, by nowo tworzone pliki miały grupę appgroup)
chmod 2770 /var/www/app/uploads

Po takiej zmianie często wymagane jest wylogowanie / restart serwisu, by członkostwo w grupie zostało odświeżone (system ładuje listę grup przy starcie procesu).

Gdy zmiana grupy jest niemożliwa (np. wiele aplikacji o różnych właścicielach), często wygodniejsze są ACL:

# dajemy www-data prawo zapisu tylko do katalogu upload
setfacl -m u:www-data:rwx /var/www/app/uploads
setfacl -m d:u:www-data:rwx /var/www/app/uploads

Jeżeli aplikacja nadal zgłasza problemy, trzeba sprawdzić również, czy sam katalog jest wykonywalny (x) dla użytkownika serwera WWW – bez tego wejście do katalogu jest blokowane:

ls -ld /var/www/app/uploads
drwxrwx--- 2 appuser appgroup ...

SELinux/AppArmor a złudne „błędy uprawnień”

Zdarza się, że wszystkie uprawnienia POSIX i ACL wyglądają prawidłowo, a aplikacja nadal zgłasza „Permission denied”. Na systemach z SELinux lub AppArmor klasyczne prawa to nie wszystko.

Na Red Hat / CentOS / Fedora częsty winowajca to SELinux. Status można sprawdzić tak:

getenforce
# lub
sestatus

Jeśli SELinux jest w trybie Enforcing, a serwer WWW nie może zapisywać w katalogu, gdzie powinien, trzeba skontrolować kontekst:

ls -Zd /var/www/app/uploads
drwxrwx---. appuser appgroup system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/app/uploads

Dla katalogów zapisu przez HTTPD oczekiwany jest zwykle typ httpd_sys_rw_content_t. Zmiana kontekstu:

# jednorazowo (do następnego przywrócenia kontekstu z polityk):
chcon -t httpd_sys_rw_content_t /var/www/app/uploads

# trwałe przypisanie (przez system polityk SELinux):
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/app/uploads(/.*)?'
restorecon -Rv /var/www/app/uploads

Na systemach z AppArmor (np. Ubuntu) trzeba przejrzeć profil serwera WWW:

aa-status
cat /etc/apparmor.d/usr.sbin.apache2

Jeżeli katalog nie jest dopuszczony w profilu (brak reguły typu /var/www/app/uploads/** rw,), AppArmor zablokuje zapis mimo poprawnych chmod/chown i ACL.

NFS, SMB i „Permission denied”, mimo że lokalnie działa

Kolejne częste źródło frustracji to współdzielone zasoby NFS/SMB. Na serwerze plik można czytać i zapisywać, lecz na kliencie montującym udział pojawia się „Permission denied”.

W przypadku NFSv3 mechanizm opiera się na identyczności UID/GID po obu stronach. Jeżeli użytkownik jan ma UID 1001 na serwerze, ale 1003 na kliencie, pojawia się konflikt. Rozwiązania są dwa:

• centralne zarządzanie użytkownikami (LDAP, FreeIPA, AD),
• lokalne ujednolicenie UID/GID (np. ręczna korekta /etc/passwd i /etc/group).

Dodatkowo NFS potrafi mapować roota na anonimowego użytkownika, przez co operacje wykonywane jako root na kliencie kończą się brakiem dostępu:

/export/dane  10.0.0.0/24(rw,sync,no_subtree_check,root_squash)

Jeżeli administracja wymaga pełnego dostępu roota z klienta (świadomy kompromis bezpieczeństwa!), używa się:

/export/dane  10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)

Przy współdzieleniu katalogów NFS między wieloma maszynami konieczne jest też spójne użycie maski i ewentualnie ACL, tak aby nowo tworzone pliki nie były „złapane” przez zbyt restrykcyjny umask na jednym z hostów.

Dla SMB/CIFS (udziały z serwerów Windows lub Samby) klasyczne chmod często działa tylko na pseudo-uprawnienia mapowane przez klienta. Kluczowe są opcje montowania:

mount -t cifs //filesrv/projekty /mnt/projekty 
  -o username=jan,uid=1001,gid=1001,file_mode=0660,dir_mode=0770

Gdy użytkownicy na kliencie widzą błędy dostępu, a administrator na serwerze Windows widzi poprawne ACL, problem zwykle leży w uid/gid i mapowaniu SID->UID, a nie w lokalnym chmod na kliencie Linux.

Skrypty backupowe, cron i różne umaski

Awaryjne przywracanie danych często ujawnia błąd: kopie zapasowe są odtwarzane z innymi uprawnieniami niż oryginał, bo skrypt backupu nie uwzględnia umaski lub nie zachowuje ACL.

Podstawowa zasada dla narzędzi backupu to używanie opcji zachowujących prawa:

# rsync z zachowaniem uprawnień, właścicieli, grup i ACL
rsync -aAX /dane/ /backup/dane/

Opcja -A przenosi ACL, a -X atrybuty rozszerzone. Bez nich przy odtwarzaniu repozytorium Gita czy katalogu projektowego często znikają dodatkowe wpisy ACL i pojawiają się błędy dostępu.

Cron uruchamia zadania w środowisku minimalnym, z domyślną umaską (często 022). Jeśli w skrypcie nie ma jawnego ustawienia umaski, utworzone pliki mogą kończyć z inną kombinacją rw- niż oczekuje aplikacja:

# na początku skryptu backup.sh
umask 027   # właściciel rw, grupa r, reszta brak

Kiedy po nocnym backupie pliki nagle stają się nieczytelne dla grupy, diagnoza zwykle zaczyna się właśnie od sprawdzenia umaski w skrypcie lub konfiguracji crona (/etc/crontab).

Błędy uprawnień przy montowaniu dysków zewnętrznych

Przy dyskach z systemem plików ext4 klasyczne chown i chmod działają normalnie. Problem zaczyna się przy FAT/NTFS, gdzie uprawnienia POSIX nie istnieją w natywnej formie. Linux emuluje je przez opcje montowania.

Typowy przykład: użytkownik nie może zapisać pliku na dysku USB podmontowanym w /media/backup. Komenda ls -l pokazuje jednolite uprawnienia dla wszystkich plików, a chmod nic nie zmienia. Rozstrzygające jest mount:

mount | grep /media/backup
/dev/sdb1 on /media/backup type vfat (rw,nosuid,nodev,uid=0,gid=0,dmask=0077,fmask=0177,utf8,shortname=mixed)

Dostęp kontroluje tutaj uid/gid i maski dmask/fmask:

# montowanie z prawami dla konkretnego użytkownika
mount -t vfat /dev/sdb1 /media/backup 
  -o uid=1000,gid=1000,dmask=0075,fmask=0175

Przy konfiguracji w /etc/fstab:

/dev/sdb1  /media/backup  vfat  rw,uid=1000,gid=1000,dmask=0075,fmask=0175  0  0

Dzięki temu nie trzeba później „naprawiać” uprawnień po montowaniu – są poprawne od razu.

Diagnostyka: jak szybko znaleźć przyczynę „Permission denied”

Zamiast ślepo poprawiać prawa, lepiej w kilku krokach ustalić, co realnie blokuje dostęp. Prosty schemat:

1. Sprawdzenie użytkownika, który faktycznie wykonuje proces:

   ps aux | grep NAZWA_PROCESU
   id NAZWA_UŻYTKOWNIKA
           

2. Sprawdzenie klasycznych praw i właścicieli:

   ls -ld PLIK_LUB_KATALOG
   namei -l /ścieżka/do/pliku
           

3. Analiza ACL:

   getfacl PLIK_LUB_KATALOG
           

4. Jeśli wszystko wygląda w porządku – kontrola SELinux/AppArmor:

   getenforce
   journalctl -t setroubleshootd -t auditd | tail
   aa-status
           

5. Na zasobach sieciowych – analiza opcji montowania:

   mount | egrep 'nfs|cifs'
           

W codziennej pracy pomaga też prosty test: uruchomienie powłoki jako konkretny użytkownik, który ma problem, i sprawdzenie dostępu „ręcznie”:

sudo -u problemuser -s
cd /ścieżka/do/katalogu
touch test.txt

Jeśli ten zestaw kroków przejdzie się spokojnie, większość zagadek z uprawnieniami daje się rozwiązać bez desperackiego używania chmod 777.

Bezpieczne wzorce zamiast „chmod 777”

Kiedy uprawnienia są popsute i rośnie presja, często pojawia się pokusa: „dajmy 777, byle zaczęło działać”. Zwykle pomaga to na chwilę, a potem wraca w postaci problemów bezpieczeństwa. Można wypracować kilka schematów, które rozwiązują te same kłopoty, ale kontrolowanie:

• współdzielony katalog roboczy – chgrp na grupę projektu, chmod 2770 i ewentualnie ACL dla dodatkowych wyjątków,
• uploads/cache/logi dla aplikacji WWW – dedykowany katalog z prawami dla użytkownika serwera WWW (grupa lub ACL),
• zadania cron/backup – jawna umaska i użycie rsync -aAX lub analogicznych opcji w narzędziu backupowym,
• serwisy systemowe – minimalne konieczne prawa, żadnych SUID „na skróty”, brak dodatkowych praw zapisu dla other.

Gdy po wprowadzeniu zmian coś nadal nie działa, pomocne bywa uproszczenie: najpierw ustawić czysty, przewidywalny stan (np. usunąć ACL setfacl -Rb, wyrównać właściciela i grupę, ustawić rozsądne chmod), potem dopiero dokładnie dokładać wyjątki za pomocą ACL czy specjalnych bitów.

Najczęściej zadawane pytania (FAQ)

Co oznacza błąd „Permission denied” w Linux i jak go naprawić?

Błąd „Permission denied” oznacza, że użytkownik nie ma wymaganych praw do pliku lub katalogu – do odczytu, zapisu lub wykonania. Najpierw sprawdź uprawnienia poleceniem ls -l ścieżka/do/pliku oraz upewnij się, że katalogi w całej ścieżce mają odpowiedni bit x (execute).

Naprawa zwykle polega na nadaniu brakujących praw lub zmianie właściciela, np. chmod u+x skrypt.sh (dodanie prawa wykonywania dla właściciela) albo chmod 640 plik dla pliku konfiguracyjnego. Jeśli plik ma być dostępny dla konkretnego użytkownika lub usługi, może być konieczne użycie chown, np. chown www-data:www-data /var/www/html/index.php.

Jaka jest różnica między chmod, chown i ACL w Linux?

chmod zmienia klasyczne prawa dostępu (r, w, x) dla właściciela, grupy i innych. chown zmienia właściciela (UID) i grupę (GID) pliku lub katalogu, co decyduje, do kogo odnoszą się poszczególne kolumny uprawnień widoczne w ls -l.

ACL (Access Control List) to rozszerzone uprawnienia, które pozwalają nadać precyzyjne prawa dodatkowym użytkownikom lub grupom, poza trzema podstawowymi klasami. Zarządza się nimi m.in. poleceniami getfacl (podgląd) i setfacl (zmiana). W praktyce ACL stosuje się, gdy klasyczny model „owner / group / others” jest zbyt ograniczony, np. w katalogach współdzielonych.

Jak czytać wynik polecenia ls -l i zrozumieć uprawnienia pliku?

Wynik ls -l wygląda np. tak: -rw-r----- 1 www-data www-data 12345 sty 5 12:34 /var/www/html/index.php. Pierwszy znak (-, d, l) oznacza typ obiektu (plik, katalog, dowiązanie). Kolejne 9 znaków (rw-r-----) to uprawnienia: trzy dla właściciela, trzy dla grupy, trzy dla innych.

Można je podzielić tak: rw- – właściciel (read, write), r-- – grupa (tylko read), --- – inni (brak praw). Dalej widzisz liczbę dowiązań, właściciela, grupę, rozmiar i datę modyfikacji. Dzięki temu łatwo ustalić, dlaczego dany użytkownik nie ma dostępu i czy trzeba użyć chmod, chown lub zmienić grupę użytkownika.

Dlaczego nie powinienem używać chmod -R 777 i co zamiast tego?

chmod -R 777 nadaje pełne prawa odczytu, zapisu i wykonania wszystkim użytkownikom dla wszystkich plików i katalogów w danym drzewie. Jest to bardzo poważne ryzyko bezpieczeństwa – każdy może modyfikować pliki, usuwać je lub uruchamiać potencjalnie groźne skrypty.

Zamiast tego:

• rozplanuj poprawne właścicielstwo (np. chown -R www-data:www-data /var/www),
• używaj bardziej restrykcyjnych masek, np. chmod -R 750 dla katalogów i 640 dla plików konfiguracyjnych,
• skorzystaj z ACL, jeśli różni użytkownicy potrzebują różnych praw w tym samym drzewie katalogów.

Dzięki temu naprawisz błędy uprawnień bez otwierania całego systemu na nieautoryzowany dostęp.

Jak rozwiązać problemy z uprawnieniami do katalogów w Linux (bit x)?

W katalogach bity uprawnień mają inne znaczenie niż w plikach. r pozwala wyświetlić listę plików, w – tworzyć i usuwać pliki, a x – wejść do katalogu i uzyskać dostęp do plików po nazwie. Brak bitu x jest częstą przyczyną błędów „Permission denied” przy cd lub otwieraniu pliku mimo pozornie poprawnych praw.

Jeśli użytkownik widzi listę plików, ale nie może wejść do katalogu ani otworzyć pliku, nadaj bit x, np. chmod u+x /sciezka/do/katalogu. Pamiętaj, że wszystkie katalogi w ścieżce muszą mieć odpowiedni bit x dla użytkownika lub jego grupy, inaczej dostęp zostanie zablokowany wyżej w drzewie.

Co to jest umask i jak wpływa na błędy uprawnień w nowych plikach?

umask określa, które bity uprawnień zostaną „wyłączone” przy tworzeniu nowego pliku lub katalogu. Sprawdzasz ją poleceniem umask, np. wartość 0022 oznacza, że katalogi będą miały domyślnie 755 (rwxr-xr-x), a pliki 644 (rw-r–r–).

Jeśli w katalogach współdzielonych nowo tworzone pliki są zbyt „ciasne” (np. tylko właściciel ma zapis), można zmienić umask na 0002, aby nowe pliki miały 664 (rw-rw-r–) i katalogi 775 (rwxrwxr-x). Zmianę zapisuje się zwykle w /etc/profile lub plikach konfiguracyjnych powłoki użytkownika, aby miała trwały efekt.

Jak sprawdzić i naprawić właściciela pliku w Linux (chown)?

Właściciela i grupę pliku sprawdzisz w kolumnach po liczbie dowiązań w ls -l, np. www-data www-data. W szerszym zakresie możesz użyć find /var/www -maxdepth 2 -ls, aby zobaczyć wielu właścicieli i grupy w jednym drzewie katalogów.

Jeśli plik należy do złego użytkownika lub grupy (np. pliki serwera WWW nie należą do użytkownika www-data), zmień je poleceniem chown, np. chown www-data:www-data /var/www/html/index.php lub rekurencyjnie chown -R www-data:www-data /var/www/html. Poprawne właścicielstwo jest kluczowe dla działania usług i uniknięcia błędów „Permission denied” mimo teoretycznie prawidłowych bitów chmod.

Najważniejsze punkty

• Błędy uprawnień w Linux najczęściej objawiają się powtarzalnymi komunikatami (np. „Permission denied”, „Operation not permitted”, „Read-only file system”), które zwykle jasno wskazują, czy problem dotyczy pliku, katalogu nadrzędnego czy całego systemu plików.
• Typowe przyczyny problemów to chaotyczne używanie chmod/chown, niepoprawne odtwarzanie backupów, przenoszenie danych między różnymi systemami plików oraz nieprzemyślane skrypty deployujące (np. „chmod -R 777”).
• Podstawowy model bezpieczeństwa Linux opiera się na trzech klasach użytkowników (owner, group, others) i trzech operacjach (read, write, execute) oraz bitach specjalnych; zrozumienie tego modelu jest kluczowe do trwałego usuwania błędów uprawnień.
• Polecenie ls -l pozwala szybko zdiagnozować problemy, pokazując typ pliku, szczegółowe prawa dostępu, właściciela i grupę, dzięki czemu można od razu ocenić, kto powinien mieć dostęp, a kto go faktycznie ma.
• Uprawnienia do katalogów działają inaczej niż do plików: bit x decyduje o możliwości wejścia do katalogu i dostępu do plików po nazwie, więc jego brak (przy samej obecności r) jest częstą przyczyną „Permission denied” przy próbie wejścia do katalogu.
• Do prawidłowego działania usług (np. serwera WWW) kluczowe jest, aby właścicielem i grupą plików były właściwe konta systemowe (np. www-data, apache), co można weryfikować i analizować m.in. za pomocą ls -l i find -ls.

Warte uwagi:

• 

  Terminal Linuxa: Podstawowe komendy, które musisz znać

• 

  REST API w Pythonie: prosta aplikacja Flask

• 

  Jak napisać prosty skrypt bash – poradnik dla…

• 

  Czym są prawa dostępu i jak je ustawiać?

• 

  Jak uratować dane z uszkodzonej dyskietki: metody,…

• 

  Przełączniki, routery, access pointy – różnice i…