Práva souborů na hostingu: chmod 644, 755, 600 a proč nikdy 777

Na sdíleném hostingu nastavte adresářům 755, souborům 644 a souboru wp-config.php 600 nebo 640. Všechny soubory by měly patřit vašemu uživateli hostingu, protože vlastník je stejně důležitý jako čísla. 777 nikdy nepotřebujete: na našem testovacím serveru se PHP soubor, který jiný uživatel serveru vložil do adresáře s 777, spustil s právy vlastníka webu a mohl přepsat libovolný soubor webu.

Jak číst práva: tři číslice, tři třídy

Každý soubor má vlastníka, skupinu a samostatná práva pro tři třídy: vlastníka, skupinu a všechny ostatní. Čtení je 4, zápis 2, spuštění 1 a každá číslice je jejich součtem: 7 znamená rwx, 6 rw, 5 r a x, 4 jen čtení, 0 nic. První číslice platí pro vlastníka, druhá pro skupinu, třetí pro všechny ostatní. Tento příkaz ukáže režimy a vlastníky jako čísla:

$ 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

U adresáře mají stejná písmena jiný význam: r vypíše soubory, w v něm vytváří, přejmenovává a maže soubory, x dovolí do adresáře vstoupit a otevřít soubory, jejichž název znáte. Proto adresáře potřebují x a běžné soubory webu ne: PHP skript se nespouští jako program, interpret ho jen čte. Ještě jeden detail, který se v testech ukázal: kdo má právo zápisu do adresáře, může v něm mazat nebo přejmenovávat soubory, i když mu nepatří.

Tabulka práv: kdo smí co a kdy je použít

Ověřeno na testovacím serveru, kde soubory patří uživateli webu a nginx i Apache běží jako www-data. Pro webový server spadají vaše soubory do „všech ostatních“, takže o tom, zda může vydat obrázek nebo styl, rozhoduje třetí číslice.

Pod jakým uživatelem běží PHP: vlastník, nebo www-data

Stejné režimy se chovají různě podle toho, pod jakým uživatelem běží PHP. V typickém hostingovém panelu běží každý pool PHP-FPM jako vlastník domény: šablona poolu obsahuje user = %user% a skupinou socketu je www-data. Starší konfigurace a servery spravované svépomocí často spouštějí PHP jako www-data, stejně jako webový server.

Malý soubor vám řekne, o který případ jde. Vložte ho do kořene webu, otevřete v prohlížeči a hned ho smažte:

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

Se stejnými právy na testovacím serveru (adresáře 755, soubory 644, vlastníkem uživatel webu) jsme dostali toto:

Závěr: když PHP běží jako vlastník, WordPress zapisuje do svých adresářů bez jakéhokoli 777 a 755 spolu s 644 úplně stačí. Druhá strana mince: škodlivý skript, který se na web dostane, získá také práva vlastníka. Prioritou proto není povolovat práva, ale zajistit, aby se takový skript nikdy nespustil.

Co vydá webový server: chmod 600 u obrázku a u PHP souboru

nginx a Apache běží jako www-data. Statické soubory čtou samy a PHP soubory předávají PHP-FPM, které je otevírá pod svým vlastním uživatelem. To vysvětluje rozdíl, který se snadno splete s chybou:

Apache takový obrázek zapíše do logu jako AH00132: file permissions deny server access, nginx jako open() ... failed (13: Permission denied) a PHP-FPM píše Unable to open primary script ... (Permission denied). Pokud soubor opravdu potřebuje 640 a webový server ho musí číst, jeho skupinou musí být www-data: s touto skupinou se obrázek vydal s 200. Další příčiny tohoto kódu popisuje náš návod k chybě 403 Forbidden. Pokud po přesunu webu zmizely jen obrázky a stránky se dál otevírají, zkontrolujte režimy ve wp-content/uploads: archivační program nebo FTP klient mohl soubory uložit s 600.

Proč je chmod 777 nebezpečné: tři testy na testovacím serveru

777 dovoluje každému procesu a každému uživateli serveru vytvářet, mazat a nahrazovat soubory. Na testovacím serveru to vypadalo takto:

1. Cizí soubor běží pod vaším jménem. Jiný uživatel serveru vložil PHP soubor do wp-content s 777. Otevřeli jsme ho v prohlížeči a skript běžel jako vlastník webu: mohl číst wp-config.php a zapisovat do index.php. Při 755 dostal tentýž uživatel „Permission denied“.
2. Ochranu lze jednoduše odstranit. Pravidlo, které blokovalo PHP v uploads, bylo v souboru .htaccess s režimem 644. Adresář ale měl 777, takže jiný uživatel .htaccess přejmenoval a testovací web shell znovu odpověděl 200. Režim samotného souboru nepomohl, protože o mazání a přejmenování rozhoduje adresář.
3. 777 otevírá dveře zranitelnému skriptu pro nahrávání. Záměrně jsme nainstalovali nahrávací skript bez kontroly přípony. S PHP jako www-data a uploads na 755 se shell.php neuložil: move_uploaded_file(): Unable to move. Po chmod 777 se uložil a spustil.

Dva další vedlejší účinky. WordPress nastavuje režim nových mediálních souborů podle režimu adresáře, takže v adresáři s 777 vycházela nahraná média s 666, zapisovatelná pro všechny. A soubory vytvořené uživatelem www-data už vlastník webu nezmění: chmod i chown vrátily „Operation not permitted“ a opravit je může jen správce serveru. Na hostingu s izolovanými účty se sousedé k vašim adresářům obvykle nedostanou, ale 777 odstraňuje poslední linii obrany.

Jak zablokovat spouštění PHP v uploads

Toto pravidlo pomáhá bez ohledu na práva: i když se škodlivý soubor dostane do uploads, server ho nespustí. Pro Apache a pro nginx před Apache vložte tento soubor .htaccess do wp-content/uploads:

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

Pro nginx bez Apache přidejte toto do bloku server nad location pro PHP, protože location s regulárními výrazy se kontrolují postupně:

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

Na testovacím serveru obě pravidla vrátila pro shell.php 403, zatímco obrázky ve stejném adresáři se dál vydávaly s 200. Další hotová pravidla najdete v našich příkladech souboru .htaccess.

wp-config.php: 600, 640, nebo 400

wp-config.php obsahuje heslo k databázi, klíčová otázka tedy zní, kdo další ho může přečíst. Při 644 jiný uživatel serveru na testovacím serveru bez námahy přečetl řádek DB_PASSWORD.

Dokumentace WordPressu doporučuje 440 nebo 400 (File Permissions, ověřeno 10. listopadu 2026). Pokud PHP běží pod vaším uživatelem, použijte 600: web funguje a sousedé soubor nepřečtou. 400 navíc brání skriptům soubor měnit, některé pluginy pro cache a zabezpečení si ale do wp-config.php samy zapisují konstanty a pak ohlásí chybu. Pokud PHP běží jako www-data, použijte 640 nebo 440 se skupinou www-data. Bez roota nemůžete souboru přidělit skupinu, jejímž nejste členem, obraťte se proto na podporu. Při 600 bez této skupiny web vracel prázdnou stránku 500 a v logu PHP bylo Failed to open stream: Permission denied in .../wp-load.php. Jak takové odpovědi číst, vysvětluje náš článek o chybě 500 Internal Server Error.

umask: proč nové soubory dostávají 644

Režim nového souboru určuje umask, která odebírá bity ze základu 666 u souborů a 777 u adresářů. Na testovacím serveru:

PHP-FPM dědí umask procesu, který ho spustil. Když jsme pool spustili s umask 002, soubory zapsané přes file_put_contents dostaly 664 a adresáře 775. Knihovna médií WordPressu se zachovala jinak: nahraná média dál dostávala 644, protože WordPress přebírá režim nadřazeného adresáře a odebírá bit spuštění. Právě proto jediné 777 na uploads vede k 666 u každého nového souboru. Přes SSH ukáže umask vaši masku a umask 022 pro danou relaci obnoví obvyklou hodnotu.

„Could not create directory“ ve WordPressu: zkontrolujte vlastníka

„Could not create directory“ při instalaci nebo aktualizaci pluginu a „Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?“ při nahrávání médií téměř vždy ukazují na špatného vlastníka, ne na příliš přísná práva. Na testovacím serveru jsme vlastníkem wp-content udělali roota, jak se stává po rozbalení archivu pod rootem. PHP běžící jako vlastník webu okamžitě narazilo na obě chyby a WordPress začal žádat údaje k FTP. Po tomto příkazu (user je zde jméno vlastníka webu)

chown -R user:user wp-content

nahrávání i instalace pluginů znovu fungovaly, aniž bychom změnili jediný režim. Pokud WordPress instalujete ručně, rozbalte archiv pod svým vlastním uživatelem; postup najdete v našem návodu, jak nainstalovat WordPress na hosting.

Jak hromadně opravit práva: příkazy find

Připojte se k hostingu přes SSH, přejděte do kořene webu a spusťte:

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

Změřili jsme tři metody na stromu WordPressu s 2 777 soubory a 284 adresáři, přičemž jsme před každým během vše nastavili na 777. Každá metoda běžela třikrát jako vlastník webu:

Na velkém webu je stonásobný rozdíl znát, používejte proto variantu s plusem. Tyto příkazy najdou problematické soubory:

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

Pokud poslední příkaz najde soubory patřící www-data nebo rootovi, chmod na ně nezabere: na testovacím serveru se hromadná oprava zastavila na souboru www-data s hláškou „Operation not permitted“. Bez SSH změňte práva ve správci souborů panelu nebo ve FileZille: položka „Oprávnění souboru“ v kontextové nabídce umí použít režim rekurzivně, jen na adresáře nebo jen na soubory.

chown: kdo může změnit vlastníka

Vlastníka souboru může změnit jen root. Na testovacím serveru skončil pokus uživatele webu předat soubor jinému uživateli hláškou „Operation not permitted“. Na sdíleném hostingu root nemáte, takže soubory s cizím vlastníkem opraví podpora nebo funkce panelu. U hostingových tarifů RichHost se weby spravují ve vlastním ovládacím panelu s asistentem AI a podpora pracuje od 10:00 do 20:00 kyjevského času a obvykle odpoví do 30 minut.

Časté dotazy

Jaká práva potřebuje WordPress?

Adresáře 755, soubory 644, wp-config.php 600. Pokud PHP běží jako www-data, potřebuje wp-config.php 640 nebo 440 se skupinou www-data. Všechny soubory by měly patřit vašemu uživateli.

Proč se po chmod 600 nenačte obrázek, ale stránka funguje?

Webový server čte obrázek jako www-data a soubor s 600 je pro něj uzavřený, proto odpoví 403. PHP soubor otevírá PHP-FPM běžící jako vlastník a tomu 600 stačí.

Potřebují PHP soubory 755?

Ne. Interpret PHP skript jen čte a bit spuštění nepotřebuje. 755 je pro adresáře a pro shellové skripty, které spouštíte ručně nebo z cronu.

WordPress při instalaci pluginu žádá údaje k FTP. Co je špatně?

PHP nemůže zapisovat do souborů webu, buď protože běží pod jiným uživatelem, nebo protože soubory mají jiného vlastníka. Na testovacím serveru vedly oba případy přesně k tomuto dotazu. Opravte vlastníka místo nastavení 777.

Jsou 775 a 664 bezpečné?

Dávají skupině právo zápisu. Pokud je váš uživatel jediným členem skupiny, riziko je malé, ale ani žádný přínos to nemá: když PHP běží jako vlastník, zápis pro skupinu není potřeba. Zůstaňte u 755 a 644.