Problemy z zapisem często kończą się poradą „daj 777 i będzie działać”. To nie jest właściwe rozwiązanie. Uprawnienia trzeba rozpatrywać razem z właścicielem plików, grupą i sposobem, w jaki PHP działa na serwerze. Ta sama wartość chmod może być poprawna w jednym środowisku i niebezpieczna w innym.
Szybka odpowiedź
Najpierw sprawdź właściciela katalogu WordPressa i użytkownika procesu PHP-FPM. Ustal, które miejsca aplikacja musi modyfikować: zwykle uploads, czasem katalogi aktualizacji i cache. Reszta powinna być możliwie ograniczona. Na zarządzanym serwerze lepiej poprawić właściciela/grupę niż otwierać zapis dla wszystkich użytkowników systemu.
chmod nie mówi wszystkiego
Tryb pliku określa prawa właściciela, grupy i innych użytkowników, ale bez informacji o właścicielu nie wiesz, kto realnie może zapisywać. Plik 644 z właściwym właścicielem bywa poprawny, a 777 daje prawo zapisu każdemu procesowi systemowemu, który ma dostęp do ścieżki.
WordPress musi zapisywać tylko tam, gdzie potrzebuje
Media trafiają do wp-content/uploads, cache może mieć własny katalog, a mechanizm aktualizacji czasem potrzebuje modyfikować pliki. Jeżeli wdrożenia robisz przez Git/CI i nie chcesz aktualizacji z panelu, model praw może być bardziej restrykcyjny. Dobierz go do procesu utrzymania, nie do jednego uniwersalnego poradnika.
wp-config.php i pliki z sekretami
Pliki zawierające dane dostępowe zasługują na szczególną ochronę. Oprócz chmodu ważne jest, czy serwer WWW potrafi przypadkiem zwrócić ich treść i czy backupy nie lądują w publicznym katalogu. Nie przechowuj kopii typu wp-config.php.old w miejscu dostępnym przez HTTP.
Po migracji właściciel często się rozjeżdża
Kopiowanie plików jako root, inny użytkownik SFTP albo narzędzie migracyjne może pozostawić właściciela niezgodnego z kontem PHP. Objawem są błędy uploadu, aktualizacji i tworzenia cache. Zanim zmienisz chmod, porównaj właściciela z działającymi katalogami i konfiguracją puli PHP-FPM.
Nie każdy zapis z WordPressa jest pożądany
Możliwość edycji plików z panelu zwiększa wygodę, ale przy przejęciu konta administratora może również zwiększyć skutki incydentu. W środowiskach zarządzanych warto ograniczać edytor plików i stosować kontrolowany proces wdrożeń. Bezpieczeństwo to równowaga między potrzebnymi funkcjami i minimalnymi prawami.
Jak potwierdzić, że naprawa naprawdę działa?
Po zmianie właścicieli i praw przetestuj trzy typy operacji: odczyt strony, zapis pliku przez WordPressa (np. upload) oraz kontrolowany deploy/aktualizację zgodnie z Twoim procesem. Następnie sprawdź, czy użytkownik PHP nie może zapisywać do miejsc, które mają pozostać tylko do odczytu. Prawidłowa konfiguracja to nie tylko „wszystko działa”, ale też „nic nie ma szerszego dostępu niż potrzeba”.
Co obserwować po zmianie?
Przejrzyj logi permission denied i właścicieli nowych plików tworzonych po zmianie. Jeżeli uploady powstają z innym właścicielem niż reszta projektu, problem wróci przy kolejnej operacji. Na serwerach z deployem przez CI zweryfikuj, że proces wdrożeniowy i PHP nie nadpisują sobie praw.
Kiedy przekazać temat dalej?
Eskaluj, gdy na jednym koncie działa kilka witryn różnych klientów albo proces PHP jest współdzielony w sposób, którego nie kontrolujesz. Wtedy izolacja użytkowników i uprawnienia są elementem architektury hostingu, nie pojedynczego chmodu.
Praktyczny scenariusz diagnostyczny
Praktyczny przypadek: WordPress nie może aktualizować wtyczek, więc ktoś ustawia 777 na całym wp-content i problem znika. Funkcja wróciła, ale bezpieczeństwo zostało pogorszone. Zamiast tego sprawdź właściciela plików, użytkownika procesu PHP i wymagany model zapisu. Dobierz minimalne uprawnienia dla katalogów i plików zgodnie z architekturą hostingu. Jeśli wdrożenia wykonuje osobny użytkownik, rozważ grupy i kontrolowany proces deploymentu. Po zmianie przetestuj upload, aktualizację i zapis cache, a jednocześnie sprawdź, czy nieautoryzowany proces nie dostał prawa modyfikacji całej aplikacji. Poprawne uprawnienia to kompromis między możliwością działania WordPressa a zasadą najmniejszych przywilejów — nie jedna magiczna liczba dla każdego serwera.
Bezpieczna kolejność działań
- Sprawdź właściciela i grupę całej instalacji.
- Ustal użytkownika procesu PHP-FPM/serwera WWW.
- Nadaj zapis tylko katalogom, które realnie go wymagają.
- Zabezpiecz
wp-config.php, backupy i pliki z sekretami. - Przetestuj upload, cache i proces aktualizacji zgodnie z modelem utrzymania.
- Po zmianie sprawdź logi 403/permission denied.
Czego nie robić
Nie stosuj chmod -R 777 na WordPressie. Nie naprawiaj problemu właściciela przez otwarcie zapisu dla wszystkich. I nie trzymaj kopii konfiguracji z hasłami w publicznym katalogu strony.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli po migracji WordPress nie może aktualizować plików albo upload zwraca permission denied, możemy ustawić właścicieli i prawa zgodnie z rzeczywistym modelem PHP, bez otwierania całej instalacji.
Źródła techniczne
Najczęściej zadawane pytania
Czy 777 jest bezpieczne?
Zwykle nie. Daje bardzo szerokie prawa zapisu i powinno być traktowane jako czerwony sygnał, a nie standardowa naprawa.
Dlaczego 755/644 czasem nie działa?
Bo znaczenie praw zależy również od właściciela, grupy i użytkownika, pod którym działa PHP.
Czy WordPress musi móc edytować wszystkie pliki?
Nie w każdym modelu. Przy kontrolowanych wdrożeniach część plików może być tylko do odczytu dla procesu aplikacji.
Czy złe prawa mogą powodować 403?
Tak, jeśli serwer nie ma prawa odczytać lub wejść do wymaganej ścieżki.