Uprawnienia plików: chmod 644, 755, 600 i dlaczego nie 777

Na hostingu współdzielonym ustaw katalogom 755, plikom 644, a plikowi wp-config.php 600 lub 640. Wszystkie pliki powinny należeć do Twojego użytkownika hostingu, bo właściciel jest równie ważny jak cyfry. 777 nigdy nie jest potrzebne: na naszym serwerze testowym plik PHP, który inny użytkownik serwera wrzucił do katalogu z 777, uruchomił się z uprawnieniami właściciela strony i mógł nadpisać dowolny plik strony.

Jak czytać uprawnienia: trzy cyfry, trzy klasy

Każdy plik ma właściciela, grupę i osobne uprawnienia dla trzech klas: właściciela, grupy i wszystkich pozostałych. Odczyt to 4, zapis 2, wykonanie 1, a każda cyfra jest ich sumą: 7 oznacza rwx, 6 rw, 5 r i x, 4 tylko odczyt, 0 nic. Pierwsza cyfra dotyczy właściciela, druga grupy, trzecia wszystkich pozostałych. To polecenie pokazuje tryby i właścicieli w postaci liczbowej:

$ stat -c '%a %U:%G %n' wp-config.php index.php wp-content
600 cw8site:cw8site wp-config.php
644 cw8site:cw8site index.php
755 cw8site:cw8site wp-content

W przypadku katalogu te same litery znaczą coś innego: r wyświetla listę plików, w tworzy, zmienia nazwy i usuwa pliki w środku, x pozwala wejść do katalogu i otworzyć pliki o znanej nazwie. Dlatego katalogi potrzebują x, a zwykłe pliki strony nie: skrypt PHP nie jest uruchamiany jak program, interpreter tylko go czyta. Jeszcze jeden szczegół, który wychodzi w testach: kto ma prawo zapisu do katalogu, może usuwać lub zmieniać nazwy plików w nim, także cudzych.

Tabela uprawnień: kto co może i kiedy ich używać

Sprawdzone na serwerze testowym, na którym pliki należą do użytkownika strony, a nginx i Apache działają jako www-data. Dla serwera WWW Twoje pliki należą do „wszystkich pozostałych”, więc to trzecia cyfra decyduje, czy może on wysłać obrazek lub arkusz stylów.

Jako który użytkownik działa PHP: właściciel czy www-data

Te same tryby zachowują się różnie w zależności od tego, jako jaki użytkownik działa PHP. W typowym panelu hostingowym każda pula PHP-FPM działa jako właściciel domeny: szablon puli zawiera user = %user%, a grupą gniazda jest www-data. Starsze konfiguracje i samodzielnie administrowane serwery często uruchamiają PHP jako www-data, tak samo jak serwer WWW.

Malutki plik pokaże, z którym przypadkiem masz do czynienia. Umieść go w katalogu głównym strony, otwórz w przeglądarce i od razu usuń:

<?php
echo posix_getpwuid(posix_geteuid())['name'], "\n";
echo is_writable(__DIR__ . '/wp-content') ? "wp-content writable\n" : "wp-content NOT writable\n";

Przy identycznych uprawnieniach na serwerze testowym (katalogi 755, pliki 644, właściciel to użytkownik strony) otrzymaliśmy:

Wniosek: gdy PHP działa jako właściciel, WordPress zapisuje do swoich katalogów bez żadnego 777, a 755 i 644 w zupełności wystarczą. Druga strona medalu: złośliwy skrypt, który trafi na stronę, też dostaje uprawnienia właściciela. Dlatego priorytetem nie jest luzowanie uprawnień, tylko dopilnowanie, żeby taki skrypt nigdy się nie wykonał.

Co wysyła serwer WWW: chmod 600 dla obrazka i dla pliku PHP

nginx i Apache działają jako www-data. Pliki statyczne czytają same, a pliki PHP przekazują do PHP-FPM, który otwiera je jako własny użytkownik. To wyjaśnia różnicę, którą łatwo wziąć za błąd:

Apache zapisuje taki obrazek w logu jako AH00132: file permissions deny server access, nginx jako open() ... failed (13: Permission denied), a PHP-FPM pisze Unable to open primary script ... (Permission denied). Jeśli plik naprawdę musi mieć 640, a serwer WWW ma go czytać, jego grupą musi być www-data: z tą grupą obrazek zwracał 200. Inne przyczyny tego kodu opisuje nasz poradnik o błędzie 403 Forbidden. Jeśli po przeniesieniu strony zniknęły tylko obrazki, a strony nadal się otwierają, sprawdź tryby w wp-content/uploads: program do archiwizacji lub klient FTP mógł zapisać pliki z 600.

Dlaczego chmod 777 jest groźne: trzy testy na serwerze testowym

777 pozwala każdemu procesowi i każdemu użytkownikowi serwera tworzyć, usuwać i podmieniać pliki. Na serwerze testowym wyglądało to tak:

1. Cudzy plik działa w Twoim imieniu. Inny użytkownik serwera wrzucił plik PHP do wp-content z 777. Otworzyliśmy go w przeglądarce i skrypt uruchomił się jako właściciel strony: mógł czytać wp-config.php i zapisywać do index.php. Przy 755 ten sam użytkownik dostał „Permission denied”.
2. Ochronę można po prostu usunąć. Reguła blokująca PHP w uploads była w pliku .htaccess z trybem 644. Ale katalog miał 777, więc inny użytkownik zmienił nazwę .htaccess i testowy web shell znów odpowiedział 200. Tryb samego pliku nie pomógł, bo o usuwaniu i zmianie nazw decyduje katalog.
3. 777 otwiera drzwi podatnemu skryptowi do wgrywania plików. Celowo zainstalowaliśmy skrypt do wgrywania bez sprawdzania rozszerzenia. Przy PHP jako www-data i uploads z 755 plik shell.php nie został zapisany: move_uploaded_file(): Unable to move. Po chmod 777 został zapisany i wykonany.

Jeszcze dwa skutki uboczne. WordPress ustala tryb nowych plików mediów na podstawie trybu katalogu, więc w katalogu z 777 wgrane pliki dostawały 666, zapisywalne dla wszystkich. A plików utworzonych przez www-data właściciel strony nie może już zmienić: chmod i chown zwracały „Operation not permitted” i naprawić to może tylko administrator serwera. Na hostingu z izolowanymi kontami sąsiedzi zwykle nie mają dostępu do Twoich katalogów, ale 777 usuwa ostatnią linię obrony.

Jak zablokować wykonywanie PHP w uploads

Ta reguła pomaga niezależnie od uprawnień: nawet jeśli złośliwy plik trafi do uploads, serwer go nie wykona. Dla Apache oraz dla nginx przed Apache umieść ten plik .htaccess w wp-content/uploads:

<FilesMatch "\.(php|phtml|phar)$">
  Require all denied
</FilesMatch>

Dla nginx bez Apache dodaj to w bloku server nad location dla PHP, bo location z wyrażeniami regularnymi są sprawdzane po kolei:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Na serwerze testowym obie reguły zwróciły 403 dla shell.php, a obrazki w tym samym katalogu nadal zwracały 200. Więcej gotowych reguł znajdziesz w naszych przykładach pliku .htaccess.

wp-config.php: 600, 640 czy 400

wp-config.php zawiera hasło do bazy danych, więc kluczowe pytanie brzmi: kto jeszcze może go przeczytać? Przy 644 inny użytkownik serwera bez trudu odczytał na serwerze testowym linię DB_PASSWORD.

Dokumentacja WordPressa zaleca 440 lub 400 (File Permissions, sprawdzono 10 listopada 2026). Jeśli PHP działa jako Twój użytkownik, użyj 600: strona działa, a sąsiedzi nie przeczytają pliku. 400 dodatkowo blokuje zmiany ze strony skryptów, ale niektóre wtyczki cache i bezpieczeństwa same dopisują stałe do wp-config.php i wtedy zgłoszą błąd. Jeśli PHP działa jako www-data, użyj 640 lub 440 z grupą www-data. Bez roota nie nadasz plikowi grupy, do której nie należysz, więc poproś o to wsparcie techniczne. Przy 600 bez tej grupy strona zwracała pustą stronę 500, a w logu PHP było Failed to open stream: Permission denied in .../wp-load.php. Jak czytać takie odpowiedzi, wyjaśniamy w artykule o błędzie 500 Internal Server Error.

umask: dlaczego nowe pliki dostają 644

Tryb nowego pliku wynika z umask, która usuwa bity z bazy 666 dla plików i 777 dla katalogów. Na serwerze testowym:

PHP-FPM dziedziczy umask procesu, który go uruchomił. Gdy uruchomiliśmy pulę z umask 002, pliki zapisane przez file_put_contents dostały 664, a katalogi 775. Biblioteka mediów WordPressa zachowała się inaczej: wgrane pliki nadal dostawały 644, bo WordPress kopiuje tryb katalogu nadrzędnego i usuwa bit wykonania. Właśnie dlatego jedno 777 na uploads kończy się trybem 666 dla każdego nowego pliku. Przez SSH umask pokazuje Twoją maskę, a umask 022 przywraca zwykłą wartość na czas sesji.

„Could not create directory” w WordPressie: sprawdź właściciela

„Could not create directory” przy instalacji lub aktualizacji wtyczki oraz „Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?” przy wgrywaniu mediów prawie zawsze oznaczają złego właściciela, a nie zbyt surowe uprawnienia. Na serwerze testowym ustawiliśmy roota jako właściciela wp-content, jak dzieje się po rozpakowaniu archiwum jako root. PHP działające jako właściciel strony od razu trafiło na oba błędy, a WordPress zaczął prosić o dane FTP. Po tym poleceniu (user to tutaj nazwa właściciela strony)

chown -R user:user wp-content

wgrywanie plików i instalacja wtyczek znów działały, bez zmiany choćby jednego trybu. Jeśli instalujesz WordPressa ręcznie, rozpakuj archiwum jako własny użytkownik; kroki opisuje nasz poradnik o tym, jak zainstalować WordPressa na hostingu.

Jak masowo poprawić uprawnienia: polecenia find

Połącz się z hostingiem przez SSH, przejdź do katalogu głównego strony i uruchom:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
chmod 600 wp-config.php

Zmierzyliśmy trzy metody na drzewie WordPressa z 2777 plikami i 284 katalogami, ustawiając przed każdym przebiegiem wszystko na 777. Każda metoda działała trzy razy jako właściciel strony:

Na dużej stronie stukrotna różnica jest odczuwalna, więc używaj wersji z plusem. Te polecenia wyszukują problematyczne pliki:

find . -perm -o+w              # writable by anyone
find . -type f -perm /111      # files with the execute bit
find . ! -user $(whoami) -ls   # files owned by another user

Jeśli ostatnie polecenie znajdzie pliki należące do www-data lub roota, chmod na nich nie zadziała: na serwerze testowym masowa poprawa zatrzymała się na pliku www-data z komunikatem „Operation not permitted”. Bez SSH zmień uprawnienia w menedżerze plików panelu albo w FileZilli: pozycja „Uprawnienia do pliku” w menu kontekstowym potrafi nadać tryb rekurencyjnie, tylko katalogom albo tylko plikom.

chown: kto może zmienić właściciela

Właściciela pliku może zmienić tylko root. Na serwerze testowym próba przekazania pliku innemu użytkownikowi przez użytkownika strony skończyła się komunikatem „Operation not permitted”. Na hostingu współdzielonym nie masz roota, więc pliki z cudzym właścicielem poprawia wsparcie techniczne lub funkcja panelu. W planach hostingowych RichHost stronami zarządza się we własnym panelu sterowania z asystentem AI, a wsparcie działa od 10:00 do 20:00 czasu kijowskiego i zwykle odpowiada w ciągu 30 minut.

FAQ

Jakich uprawnień potrzebuje WordPress?

Katalogi 755, pliki 644, wp-config.php 600. Jeśli PHP działa jako www-data, wp-config.php potrzebuje 640 lub 440 z grupą www-data. Wszystkie pliki powinny należeć do Twojego użytkownika.

Dlaczego po chmod 600 obrazek się nie ładuje, a strona działa?

Serwer WWW czyta obrazek jako www-data, a plik z 600 jest dla niego zamknięty, więc odpowiada 403. Plik PHP otwiera PHP-FPM działające jako właściciel, a do tego 600 wystarcza.

Czy pliki PHP potrzebują 755?

Nie. Interpreter tylko czyta skrypt PHP i nie potrzebuje bitu wykonania. 755 jest dla katalogów i dla skryptów powłoki, które uruchamiasz ręcznie lub z crona.

WordPress prosi o dane FTP przy instalacji wtyczki. Co jest nie tak?

PHP nie może zapisywać do plików strony, bo albo działa jako inny użytkownik, albo pliki mają innego właściciela. Na serwerze testowym oba przypadki dawały dokładnie to pytanie. Popraw właściciela zamiast ustawiać 777.

Czy 775 i 664 są bezpieczne?

Dają grupie prawo zapisu. Jeśli Twój użytkownik jest jedynym członkiem grupy, ryzyko jest małe, ale korzyści też nie ma: gdy PHP działa jako właściciel, zapis dla grupy nie jest potrzebny. Zostań przy 755 i 644.