cPanel Question posted in
The official documentation can be seen here.

SessionHandler::gc(): ps_files_cleanup_dir | Permission denied (13) – CPanel

i have a problem with PHP7 in CentoOS (WHM/CPANEL) and Prestashop 1.7

the system gives me this messagges:

Notice on line 429 in file /home/onywf3fr9a/public_html/app/cache/dev/classes.php
[8] SessionHandler::gc(): ps_files_cleanup_dir: opendir(/var/cpanel/php/sessions/ea-php70) failed: Permission denied (13)

Tags:

6

Answers


  1. 0

    For fixing the

    «Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir("/var/cpanel/php/sessions/ea-php70") failed: Permission denied"

    I recommend to grant the write access rights for this particular folder (/var/cpanel/php/sessions/ea-php70) to the operating system account you use for the PHP interpreter.

    Disabling the PHP’s session garbage collector with the session.gc_probability=0 PHP setting is not a good solution, because you will have a lot of orphaned session files in the session folder, and it will waste the disk space and slow down your server.

    Login or Signup to reply.
  2. 0

    I have the same issue, I changed the session.save_pathphp.ini to “/tmp” in my php.ini

    Login or Signup to reply.
  3. 0

    This error occurs, because you need folder permission to store your session files in the session folder.

    This error is common for all popular frameworks. Solution is
    1. Give permission to the session folder as showing to store files OR
    2. create a local session folder in your project and rewrite the session files storing path in your project.

    Login or Signup to reply.
  4. 0

    I cleared cache and problem has been solved 🙂

    Login or Signup to reply.
  5. 0

    Background

    This error occurs when PHP tries to garbage collect expired sessions, but the directory containing the session files is not listable (missing the r access bit) by the user PHP runs as.

    This is usually a security measure against PHP session hijacking. E.g. Debian sets the permissions for the session directory to drwx-wx-wt. These permissions allow anyone to create sessions and the user who created the session may read it again if they knows the file name (session id), but only root can get a list of all active sessions.

    Distributions with this configuration normally also set up a cronjob or timer that regularly cleans up the sessions and disable the native garbage collection in php.ini: session.gc_probability = 0.

    Possible Causes

    1. You or someone else modified the php.ini and changed session.gc_probability to a value other than 0.
    2. A PHP script uses ini_set() to modify session.gc_probability at runtime. Some PHP frameworks are prone to this. E.g. Symfony always sets session.gc_probability to 1 if not configured otherwise.
    3. You or someone else managing the server botched up the session directory permissions on a system that doesn’t use a cronjob or timer to cleanup expired sessions.

    Solutions

    1. Change session.gc_probability in php.ini to 0 after verifying that your installation uses a cronjob/timer for session cleanup.

      • CPanel uses /usr/local/cpanel/scripts/clean_user_php_sessions to remove expired sessions, so all CPanel installations use a cronjob.
      • Debian, Ubuntu and Linux Mint use a systemd timer phpsessionclean.timer for session cleanup.

    2. Prevent the web application from overriding session.gc_probability. For Symfony based applications this can be done by modifying config/packages/framework.yaml:

      framework:
    session:
        gc_probability: null

    3. If your system really uses the native session garbage collection instead of a cronjob or timer, change the permissions of the session folder to allow listing for the user running PHP:

      # Check beforehand which group php-fpm runs as. Here I assume www-data:
chgrp www-data /var/cpanel/php/sessions/ea-php70
chmod g+r /var/cpanel/php/sessions/ea-php70

      Security notice: Changing the permissions allows any PHP script to enumerate all active session ids and potentially access all sessions. Only do this if you are sure the solutions above aren’t applicable!

    4. (Potentially dangerous) Change session.save_path to /tmp or a similar directory that PHP can access for reading and writing.

      Security notice: Changing the session save path to a world-readable directory allows any program and any PHP script to enumerate all active session ids and potentially access all sessions. Only do this if you are sure the solutions above aren’t applicable!

    Login or Signup to reply.
  6. 0

    While this is not exactly elegant, I have found a solution that works for me at least. I noticed if I simply wait a second and refresh the page, I get though. I get this error when I am testing and going back and forth pages quickly.

    $count = 0;

  do {
    if (@session_start()) {
      break;
    }
    sleep(1);
    $count++;
  } while ($count < 4);

    While this creates a slight delay, and it doesn’t create an infinite loop, it seems to give the server to catch up on things.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search