opendir(/var/cpanel/php/sessions/ea-php56) failed: Permission denied (13)

[runastoreperu]

Hello friends when entering the administration part of the store I find this error when I want to go to the catalog option of the store to enter new products, please could help me, I know it is a php error, but I can not find the Solution, the error says so:

 

 

ContextErrorException in classes.php line 429: Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php56) failed: Permission denied (13)

1. in classes.php line 429
2. at ErrorHandler->handleError('8', 'SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php56) failed: Permission denied (13)', '/home/wwwrunastoreperu/public_html/app/cache/dev/classes.php', '429', array('maxlifetime' => '1440'))
3. at SessionHandler->gc('1440') in classes.php line 429
4. at SessionHandlerProxy->gc('1440')
5. at session_start() in classes.php line 117
6. at NativeSessionStorage->start() in classes.php line 192
7. at NativeSessionStorage->getBag('attributes') in classes.php line 492
8. at Session->get('_security_main') in ContextListener.php line 78
9. at ContextListener->handle(object(GetResponseEvent)) in classes.php line 2604
10. at Firewall->onKernelRequest(object(GetResponseEvent), 'kernel.request', object(TraceableEventDispatcher))
11. at call_user_func(array(object(Firewall), 'onKernelRequest'), object(GetResponseEvent), 'kernel.request', object(TraceableEventDispatcher)) in WrappedListener.php line 61
12. at WrappedListener->__invoke(object(GetResponseEvent), 'kernel.request', object(ContainerAwareEventDispatcher))
13. at call_user_func(object(WrappedListener), object(GetResponseEvent), 'kernel.request', object(ContainerAwareEventDispatcher)) in classes.php line 1863
14. at EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.request', object(GetResponseEvent)) in classes.php line 1778
15. at EventDispatcher->dispatch('kernel.request', object(GetResponseEvent)) in TraceableEventDispatcher.php line 140
16. at TraceableEventDispatcher->dispatch('kernel.request', object(GetResponseEvent)) in bootstrap.php.cache line 3236
17. at HttpKernel->handleRaw(object(Request), '1') in bootstrap.php.cache line 3206
18. at HttpKernel->handle(object(Request), '1', false) in bootstrap.php.cache line 3360
19. at ContainerAwareHttpKernel->handle(object(Request), '1', false) in bootstrap.php.cache line 2562
20. at Kernel->handle(object(Request), '1', false) in index.php line 86

 

[FuenRob]

Hello,

 

I had the same problem. 

 

I solved it by changing the session_path to / tmp, in the php.ini

 

Regards

Edited June 13, 2017 by FuenRob (see edit history)

[selectshop.at]

As FuenRob said. it is a server configuration problem, follow his instructions and report if solved. If not than you should contact your provider and he should solve the server configuration problem.

[marcoskm]

In my case,i had uploaded an 1.6 module to prestashop 1.7.

I had to restore an backup,because it was not possible to see and delete the module.

 

[erkange]

On 6/13/2017 at 0:19 PM, FuenRob said:

Hello,

 

I had the same problem. 

 

I solved it by changing the session_path to / tmp, in the php.ini

 

Regards

Hi

Could you please give me more details. How did you do it?

I use cPanel

[FuenRob]

On 30/12/2017 at 8:55 PM, erkange said:

Hi

Could you please give me more details. How did you do it?

I use cPanel

 

In the files of your web (DocummentRoot), do you have the file php.ini?

[erkange]

On 1/2/2018 at 8:11 PM, FuenRob said:

 

In the files of your web (DocummentRoot), do you have the file php.ini?

 

I have VDS, so i can reach to php.ini. But what change i need to do exactlty? 

I have below line in php.ini, 

session.save_path = "/var/cpanel/php/sessions/ea-php56"

 

do you suggest to change it to below one?

session.save_path = "/tmp"

 

[FuenRob]

On 6/1/2018 at 6:52 PM, erkange said:

 

I have VDS, so i can reach to php.ini. But what change i need to do exactlty? 

I have below line in php.ini, 

session.save_path = "/var/cpanel/php/sessions/ea-php56"

 

do you suggest to change it to below one?

session.save_path = "/tmp"

 

 

Yes, you must done this change.

Please, comment with your results.

[erkange]

1 hour ago, FuenRob said:

 

Yes, you must done this change.

Please, comment with your results.

 

thanks it worked. 

I have done below updates;

 

max_execution_time = 600     ; Maximum execution time of each script, in seconds

max_input_time = 600 ;  Maximum amount of time each script may spend parsing request data

memory_limit = 128M      ; Maximum amount of memory a script may consume (32MB)

max_input_vars = 7000 ;

 

session.save_path : /tmp

[FuenRob]

1 hour ago, erkange said:

 

thanks it worked. 

I have done below updates;

 

max_execution_time = 600     ; Maximum execution time of each script, in seconds

max_input_time = 600 ;  Maximum amount of time each script may spend parsing request data

memory_limit = 128M      ; Maximum amount of memory a script may consume (32MB)

max_input_vars = 7000 ;

 

session.save_path : /tmp

 

Perfect

[jetx]

Was also having this error with 1.73. prestashop.

Edited March 25, 2018 by jetx (see edit history)

[Designinfo.in]

I have this same error, changed the path file to /tmp in php.ini yet the same error is showing.

[LZGexar]

i changed the path file.

Worked like a charm! 

Thanks 😀

[Kogkalidis]

On 6/13/2017 at 12:19 PM, FuenRob said:

Hello,

 

I had the same problem. 

 

I solved it by changing the session_path to / tmp, in the php.ini

 

Regards

@FuenRob you made my day ❤️

Issue resolved using your advice in v.1.7.6.4 (latest at the time of composing this message)

Edited March 10, 2020 by tapanda.gr (see edit history)

[Cherniakovsky]

Hi, i have the same issue. In fact the solution of change the session.save_path to /tmp works fine but only in debug mode, when i change the debug mode to off the problem error 500 still there.

[Luzotaiza]

Hello good evening, I have exactly the same problem ... When loading products the store keeps loading and with the debug it gives the error: SessionHandler :: gc (): ps_files_cleanup_dir: opendir (/ var / cpanel / php / sessions / ea-php73) failed: Permission denied (13) I tried with changing php.ini and php ini variables but nothing

[Sandro Airaldi]

@Luzotaiza @ Cherniakovsky Ho LO STESSO Problema, Momento in cui la Modalità di eseguire il debug E disabilitata VIENE restituito L'errore 500. Come hai risolto? Grazie @tapanda.grIn debug it is true it resolves but as soon as I deactivate the debug error500 returns

Edited November 11, 2020 by Sandro Airaldi (see edit history)

[Juan Rios1]

On 1/8/2018 at 4:51 AM, erkange said:

 

thanks it worked. 

I have done below updates;

 

max_execution_time = 600     ; Maximum execution time of each script, in seconds

max_input_time = 600 ;  Maximum amount of time each script may spend parsing request data

memory_limit = 128M      ; Maximum amount of memory a script may consume (32MB)

max_input_vars = 7000 ;

 

session.save_path : /tmp

Fixed my problem as well!

Thanks

[mikhailjb]

On 6/13/2017 at 7:19 PM, FuenRob said:

Hello,

 

I had the same problem. 

 

I solved it by changing the session_path to / tmp, in the php.ini

 

Regards

I set some settings in a shipping module and also set Address Phone field to mandatory for customers and suddenly it was crashing my dashboard with this error 

Notice on line 101 in file /home/***/***l/vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/Handler/StrictSessionHandler.php
[8] SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php73) failed: Permission denied (13)
 

Great fix sorted it out straight away.

Thanks for posting this.

 

[ericksonvornes]

the solution of change the session.save_path to /tmp works fine but only in debug mode, when i change the debug mode to off i see nothing, only white screen, need help

[ericksonvornes]

On 10/21/2020 at 11:03 AM, Cherniakovsky said:

Hi, i have the same issue. In fact the solution of change the session.save_path to /tmp works fine but only in debug mode, when i change the debug mode to off the problem error 500 still there.

Did you solved??

[Paul Buisson]

I changed the session.save_path to /tmp , but now when trying to take out of debug mode, the error about the ps_files_cleanup_dir: opendir (/var/cpanel/php/sessions/ea-phpXX.. repeats. The debug mode turn off is still trying to act upon the previous setting. I am in debug mode in an incognito browser, and have manually cleared caches in the shop and in the browser.

[Paul Buisson]

my issue turned out to be custom coding elsewhere in the site breaking prestashop functions. removing the custom code allowed everything to work as designed.

[Jesús David Ariza]

On 1/8/2018 at 5:51 AM, erkange said:

 

thanks it worked. 

I have done below updates;

 

max_execution_time = 600     ; Maximum execution time of each script, in seconds

max_input_time = 600 ;  Maximum amount of time each script may spend parsing request data

memory_limit = 128M      ; Maximum amount of memory a script may consume (32MB)

max_input_vars = 7000 ;

 

session.save_path : /tmp

Hello, here reporting from the future (2022) and I have the same problem. With this solution, did you fix this issue forever and ever? I

[Paul Buisson]

issue had returned in PS 1.7.8.5

I had tried repeatedly editing the php.ini session.save_path to /tmp - to no improvement (even with clearing cache).

My fix was to instead make the the directory change in the cpanel multiphp INI and then clear the cache. Apparently, at least with my server setup, the mod from the cpanel dashboard does more than just the line edit of the php.ini (while it does do that as well). Maybe it's a matter of a setting that cannot be overridden by simply doing the line edit of the php.ini .

Now I finally have debug mode back, and can confidently upgrade, again.

Edited November 1, 2022 by Paul Buisson
left word out (see edit history)

[need2011]

I am using PS 1.7.8.8

I tried the /tmp That did not work it crashed my whole site so I had to put it all back.

Now I'm trying change session.gc_probability in php.ini to 0 and use cron job.  I do use cpanel.  My hosting company said that it automatically sets up cron jobs?

It seems that it has not worked.

I can access the back office but the minute that I click on anything it goes to Whoops, looks like something went wrong.  I cannot even get it out of debugging mode.

Is there any fix for this?

[sucknorris]

Same Problem here:

changing to /tmp doesnt work.

I run my own server with WHM, seems like i need to give somewhere permission, someone can help me please?

Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php81) failed: Permission denied (13)

[need2011]

I don't know if this will help you with a WHM  I use cpanel

This is how I fixed the problem

php ini  session.save_path    I changed the path to a new folder that I made

/public_html/YourSite.com/sessions

All errors went away.

This fixed my problem hope it helps.

[sucknorris]

Thanks, i did the same.

For some reason i really had to create a new folder and give for dev 755 permission, and for production i can change it back.

[Simbiosis]

Hello there!

After many hours, I want to share this experience in case anyone in 2023 finds this information useful.

It is definitely a server issue, not a Prestashop issue.

There are several ways to detect the problem, you have to try one or all ways until you find the break.

There are 2 places where users and/or groups are configured:

Nginx and PHP (with or without FPM)

Sessions are normally found in original php route, although after trying other ways, you can choose a specific route without problems.

In one of the tests I changed /var/lib/php/session to this other route /usr/share/nginx/html/session without problems.

That route can exist in more than one location.

/etc/php.ini
/etc/php-fpm.conf
/etc/php-fpm.d/www.conf

There are servers or linux distributions that have different configurations.

For example, I saw in many forums that the solution was to change the php.ini and change session_path to /tmp, but sometimes that place is the wrong one, because that configuration is handled by FPM if that is your case.

Within the path /etc/php-fpm.d/www.conf you will find the option
php_value[session.save_path], and that's where you should modify a new path (only if it makes sense to you), because it's not necessary in many cases.

The main problem has to do with the console users that you have configured in nginx.conf and/or the PHP or PHP-FPM configuration files.

Review user, group and permissions of:

/usr/share/nginx/html/ (Or the path that points to your prestashop home)

/var/lib/php/ (or the equivalent path on your operating system)

/var/lib/nginx/  (or the equivalent path on your operating system)

After that, check the users who are running Nginx, PHP or PHP-FPM to confirm if they are the same. You can use anyone, apache, nginx, ec2-user, etc.

The username and group is just an example, use the one that suits you best and define it with security in mind.

In theory it is not necessary to modify the php.ini, in my case at least, after modifying it 100 times, I was able to verify that it is not required at all.

If you use PHP-FPM as in my case, the files you should import are php-fpm.conf or www.conf, In those 2 you will find everything you need, user and group.

In my case these two option didn't add value at all, so I left them disabled.

;listen.owner = nginx
;listen.group = nginx

The only one that worked for me was this:

listen.acl_users = apache,nginx

If you have listen.acl_users turned on, the listen.owner and listen.group options will be ignored.

With all this information you should review the following:

Example:

user nginx; on /etc/nginx/nginx.conf or the equivalent path

user=nginx and group=nginx on /etc/php-fpm.d/www.conf or the equivalent path

sudo chown -R nginx:nginx /var/lib/nginx/ or the equivalent path

sudo chown -R /var/lib/php/ or the equivalent path

sudo chown -R nginx:nginx /usr/share/nginx/html/ or the equivalent path

You should also review the read and write permissions that the folders and files have, because depending on the server or hosting, 755 is required.

It always stops Nginx and PHP-FPM after modifying those parameters.

You must clear the cache of the "cache" folder in Prestashop, or you may get a Doctrine error or similar.

Users must have read and write permissions, paths must authorize those users, and files must have read and write permissions. Sometimes the user running PHP has permissions to start the service and access their logs or sessions, but they don't have permissions to the prestashop HTML folders.

I hope this helps someone.

Maybe I'm missing something, but I'll be happy to add something if you ask or request it.