Jak mohu opravit chybu oprávnění při volání session_start ()?

budete muset změnit direktivu session.save_path php.ini

Můžete to provést pomocí session_save_path

Pokud máte SSH přístup, zde je návod, jak opravit oprávnění a vlastnictví

Sudo chown -R NAME_OF_USER /tmp

Nahraďte NAME_OF_USER uživatelem, pod kterým běží php. Naleznete jej jednoduchým vložením těchto řádků do souboru php:

$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;

Navíc budete chtít použít ini_set('session.save_path', '/dir/here'); za předpokladu, že máte přístup k této funkci. Ostatní navrhované způsoby jsou platné.

Uvědomuji si, že se jedná o starý příspěvek, ale právě jsem narazil na tento problém a našel snadné řešení.

Pro mě se tento problém děje s jedním z mých webových stránek nasazených lokálně. Nezkoušel jsem přistupovat k webovým stránkám pomocí jiných prohlížečů, ale dělal se pokaždé, když jsem se pokusil o přístup k těmto stránkám prostřednictvím prohlížeče Chrome. Rozhodl jsem se jít do vývojářských nástrojů Chrome pod kartu aplikace a kliknout na tlačítko Vymazat úložiště. Voila - všechno funguje znovu jako kouzlo. 

Doufám, že to pomůže někomu jinému!

Měl jsem přesně stejný problém s jedním z mých skriptů PHP a byl jsem rád, co jsem se rozešel, protože to fungovalo perfektně den předtím a provozuji ho z vlastního místního stroje Puppy Linux takže to není ani Host, ani nic.

Jediné, co jsem předtím dělal, bylo snaha dostat Javu do práce s webovým prohlížečem, takže některé, jak se mi podařilo dostat Javu do práce, ale rozbil PHP - oops!

Každopádně jsem si vzpomněl, že zatímco jsem se snažil dostat Java do práce, odstranil jsem obsah složky/tmp, abych vymazal cokoliv, co by mohlo být příčinou problému (ve skutečnosti se ukázalo, že s Java jsem používal starý plugin oij s novým Firefoxem )

Pro vyřešení tohoto problému jsem otevřel Rox File Manager, šel do složky/a kliknul vpravo na tmp folder -> Mount Point 'tmp' and clicked properties.

Všiml jsem si, že oprávnění byla nastavena jako Vlastník - Čtení, Zápis, Exec, ale Skupina a Svět byly nastaveny pouze na čtení a Exec a ne zápis. Zaškrtnutím políčka Psát pro skupinu i Svět a nyní PHP opět funguje.

Nevím, v jakém okamžiku musí být oprávnění pro tmp změněna, ale pro PHP musí být nastaveno na oprávnění pro zápis.

Měl jsem tento problém v následující situaci:

1. Vyplnil jsem několik relací s PHP
2. Zatímco byla relace stále aktivní, změnila jsem z PHP 5.4 na 5.3 na hostitele.
3. Znovu načtením stránky došlo k chybě popsané výše.
4. Znovu nastavte PHP verzi na 5.4.
5. Použité session_unset (); a session_destroy (); k vyčištění aktuální relace.
6. Změnila verzi PHP zpět na 5.3.
7. Teď to funguje znovu.

Závěr: Z irelevantního důvodu jsem musel změnit verzi PHP a při přepínání s relacemi naživu se relace poškodily.

Zkontrolujte, zda se nezobrazují problémy s prostorem na disku. Pokud jsou všechna oprávnění správná (a 777 by to mělo udělat pro vás), můžete tuto chybu (pro některé verze PHP a Apache mít stále k dispozici), pokud není dostatek místa pro zápis do disk.

Mám stejný problém s povolením, ale na/var/lib/php/session /.

Chcete-li to opravit, vymažu soubor a restartuji php-fpm.

rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
Sudo service php5.6-fpm restart

Teď vše funguje dobře.

Přidejte následující řádek

ini_set('session.save_path', getcwd() . '/tmp');

před 

session_start(); 

Pokud:

• session.gc_probability> 0
• soubory relací jsou vytvořeny jiným uživatelem (např. root a Apache).
• soubory relací jsou uloženy na stejném místě (např./var/lib/php/session)

Pak se zobrazí tato chyba, např. Apache PHPproces se pokusí spustit sbírku odpadů na souborech relace.

Opravy:

1. Překonfigurujte PHP tak gc_probability je 0, a mít úlohu cron odebrání starého/stale soubor (y).
2. Každý jiný uživatel uloží své soubory relací do samostatných míst (session_save_path () atd.).

pokud používáte webový server Apache, rychlá oprava je přejít na příkazový řádek a typ:

open /etc/Apache2/

pak z otevřeného okna otevřete soubor s názvem httpd.conf a vyhledejte User nebo Group změňte tyto 2 řádky na:

User  _www
Group _www

Je to proto, že chcete, aby váš server měl svolení k systémovým adresářům, zejména chcete změnit User, nebo můžete Group nechat na staff nebo admin.

Zpočátku jsem měl tento problém kvůli nginx vlastnící/tmp umístění a php-fpm byl spuštěn pod 'Apache' uživatele a skupiny kvůli www.conf. Vyměnil jsem uživatele/skupinu v tomto souboru a pak to fungovalo dobře. Chcete-li ověřit <?php echo exec('whoami'); ?>, můžete zkontrolovat.

Pomocí PHP 5.6 jsem již použil session_save_path (), abych ukázal na adresář ve struktuře domény. Fungovalo to dobře, až jsem upgradoval na PHP 7.0, kdy jsem obdržel zaznamenanou chybu. Na PHP.net Našel jsem několik komentářů, které naznačují, že přiřazení přímé cesty nefungovalo vždy, takže jsem použil jejich návrh.

session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));

fungoval perfektně. Nezapomeňte změnit /../session na relativní umístění aktuálního adresáře relace.

Pro mě se zdá, že problém je chyba WHM! Mám spoustu add na doménách a vše funguje dobře, ale s subdoménou to přináší tuto chybu.

Podivná věc, ale pokud používám úplnou adresu URL s hlavní doménou, funguje správně:

main-domain.com/my.subdomain.com

Pokud používám subdoménu přímo, přinese to "Oprávnění odepřeno (13)":

my.subdomain.com

Jde o to, že kořen všech domén addon je:

/ home/xx /

Ale pro mou subdoménu nevím proč, kořen je: (Neměl bych mít přístup k tomuto dir)

/

Takže je to opravdu snaha dosáhnout:/tmp místo/home/xx/tmp

Které také existuje, ale nemají správná oprávnění

Pro objasnění jsou to příklady celé cesty:

/ home/my-account/public_html

/ home/můj účet/tmp

/ tmp

Řešené řešení bylo: 

session_save_path ('/ home/my-account/tmp');

session_start ();