cPanel & WHM 64 PHP session path errors
Since upgrading a few servers today to cPanel64 PHP temp paths are default to /var/cpanel/php/sessions/ea-phpXXXX (XXXX being version).
But it has stopped individual sites from being able to write sessions.
PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/cpanel/php/sessions/ea-php56) in Unknown on line 0
I've changed the default via MultiPHP manager to set it to /tmp but that directory does exist. What do I need to do to get PHP to recognise the new default save_path directories?
-
I am having the same problem with some account,s did something go wrong with the update? 0 -
After the server updated last night we are getting quite a few php errors on different sites. From what I can tell php itself has not changed.. Mainly: open_basedir, MCrypt and session errors (Read-only file system) 0 -
I thought it would be a problem to change the session path. As expected, after the 11.64 update, the session can not write to the session with the change of the path. Do not update 11.64. Something is broken every time an update is made. I'm tired of this. Please do not change anything anymore. 0 -
Can confirm also having issues with permissions on folders/session paths 0 -
Same here. Since the update today the session path is set to /var/cpanel/php/sessions/ea3 Setting this folder rights to 777 did not help. (chmod 777 -R /var/cpanel/php/sessions/ea3) ---edit--- I have regained control back by setting the session_path back to /tmp More info on my PHP config Default PHP Version: 5 PHP 5 Handler: dso Apache suEXEC: on Apache Ruid2: on 0 -
I think they relate to the following. Fatal error: Uncaught PHP Warning: Unknown: open(/var/cpanel/php/sessions/ea3/sess_e9bcb62efbea018a31915d6460, O_RDWR) failed: Read-only file system (30) thrown in Unknown on line 0 var/cpanel/php/sessions/ea3/ is empty 0 -
I have regained control back by setting the session_path back to /tmp
This worked for me too0 -
I fixed this by setting the session_path back to /tmp as shown on New Thread - cPanel & WHM 64 PHP session path errors 0 -
Just to confirm is it to be set to /tmp or is there a different path? I've honestly never seen this setting prior to the issue today 0 -
Same here. I have regained control back by setting the session_path back to /tmp
Worked for me, but I believe that cPanel must investigate why this is happening. We should be able to use the new default save_path. My current configuration: [SPOILER="My configuration...">cPanel + Cloudlinux Apache 2.4 config config-runtime mod_asis mod_authn_dbm mod_authn_socache mod_bwlimited mod_cgi mod_dbd mod_deflate mod_env mod_expires mod_headers mod_hostinglimits mod_mpm_prefork mod_proxy mod_proxy_fcgi mod_proxy_http mod_security2 mod_ssl mod_suexec mod_suphp mod_unique_id mod_version tools PHP 5.4 libc-client pear php-bcmath php-calendar php-cli php-common php-curl php-devel php-exif php-fpm php-ftp php-gd php-gettext php-iconv php-imap php-ioncube php-litespeed php-mbstring php-mcrypt php-mysqlnd php-pdo php-posix php-pspell php-soap php-sockets php-xml php-xmlrpc php-zendguard php-zip runtime PHP 5.5 libc-client pear php-bcmath php-calendar php-cli php-common php-curl php-devel php-exif php-fpm php-ftp php-gd php-gettext php-iconv php-imap php-ioncube php-litespeed php-mbstring php-mcrypt php-mysqlnd php-pdo php-posix php-pspell php-soap php-sockets php-xml php-xmlrpc php-zendguard php-zip runtime PHP 5.6 libc-client pear php-bcmath php-calendar php-cli php-common php-curl php-devel php-exif php-fpm php-ftp php-gd php-gettext php-iconv php-imap php-ioncube php-litespeed php-mbstring php-mcrypt php-mysqlnd php-pdo php-posix php-pspell php-soap php-sockets php-xml php-xmlrpc php-zendguard php-zip runtime Others apr apr-util cpanel-tools documentroot libcurl libmcrypt modsec-sdbm-util php-cli profiles-cpanel0 -
Just set it to /tmp.. To do this go to the PHP Configuration Editor and change session.save_path to /tmp. I'm not sure if this is a long term fix but it stoped all the errors that I'm getting. 0 -
Hello @Jan-Paul Kleijn, For non-CloudLinux systems, you can temporarily change the value for "session.save_path" to /tmp via "WHM >> Software >> MultiPHP INI Editor >> Basic Mode" for each version of PHP installed on the system. However, ensure to revert this value back to "/var/cpanel/php/sessions/ea-php$$" once we publish a resolution. Thank you. 0 -
I don't have a /etc/cagefs/ folder.. I have a similar setup to Jan-Paul above. - CENTOS 6.7 x86_64 xen pv - WHM/cPanel 64.0 - Default PHP Version: 5 - PHP 5 Handler: dso - Apache suEXEC: on - Apache Ruid2: on 0 -
Hi @Legin76, Please see my response above your post: Post 15 Thank you. 0 -
Hi Michael, Thanks for your update ! Is this definitely considered as fixed in 64.0.3 ? Also for non-CloudLinux systems ? Because we somehow still experience it today (having 64.0.3). I still put in "/tmp" for the time being... Kind regards 0 -
Thanks for your update ! Is this definitely considered as fixed in 64.0.3 ? Also for non-CloudLinux systems ? Because we somehow still experience it today (having 64.0.3). I still put in "/tmp" for the time being...
Hello @acolad, Yes, the issue should have been addressed with case CPANEL-12279. Could you open a support ticket using the link in my signature so we can take a closer look at your system? You can post the ticket number here so we can update this thread with the outcome. Thank you.0 -
Hello, If anyone else on a CentOS system continues to encounter this issue after updating to cPanel 64.0.3 or higher, try running the following commands to see if it clears up the problem: /scripts/clear_orphaned_virtfs_mounts --clearall ; /scripts/update_users_jail ; /scripts/restartsrv_httpd
Thank you.0 -
This appears to have fixed sites using php 5.6 but not 7.1. 0 -
This appears to have fixed sites using php 5.6 but not 7.1.
Hello, Does running the commands referenced in my previous response help? If not, feel free to open a support ticket using the link in my signature so we can take a closer look. You can post the ticket number here and we will update this thread with the outcome. Thank you.0 -
I want to ask a question michael. Would not it be better to implement this session change only on new installations? On a server using 11.62, the transition to 11.64 seems to cause many different problems that are not anticipated to be automatically changed in the session path. It should be considered well when implementing such significant changes in working servers. 0 -
Hello @Legin76, It looks like the /var/cpanel/php/sessions/ea-php71 directory is not automatically created for PHP 7.1. CPANEL-12361 is open to report this issue. I'll update this thread with more information on the status of this case as it becomes available. In the meantime, try manually creating the directory and let us know if that helps: mkdir /var/cpanel/php/sessions/ea-php71 chmod 4733 /var/cpanel/php/sessions/ea-php71
Thank you.0 -
Hello @Legin76, It looks like the /var/cpanel/php/sessions/ea-php71 directory is not automatically created for PHP 7.1. CPANEL-12361 is open to report this issue. I'll update this thread with more information on the status of this case as it becomes available. In the meantime, try manually creating the directory and let us know if that helps:
mkdir /var/cpanel/php/sessions/ea-php71 chmod 4733 /var/cpanel/php/sessions/ea-php71
Thank you.
That worked.. Thanks0 -
I want to ask a question michael. Would not it be better to implement this session change only on new installations? On a server using 11.62, the transition to 11.64 seems to cause many different problems that are not anticipated to be automatically changed in the session path. It should be considered well when implementing such significant changes in working servers.
You would think that would be the logic developers would use... But no, someone decided to change things around for the heck of it without proper testing and broke a bunch of our and our clients' sites in the process, having us scrambling to figure out what in the world happened and how to fix it...0 -
I want to ask a question michael. Would not it be better to implement this session change only on new installations? On a server using 11.62, the transition to 11.64 seems to cause many different problems that are not anticipated to be automatically changed in the session path. It should be considered well when implementing such significant changes in working servers.
Hi vacancy, The change was done as security hardening measure. By default, PHP saves its session files to /tmp. This allows users on the system to view other users session files. In general we try not to change paths or file locations unless its for security or compatibility reasons.0 -
Hi all, Yes, the command provided by Michael indeed corrects the issue. After having upgraded we still encountered the problem but after we launched the said command everything's back at it's best. THANKS a lot ! 0 -
Hi , I am facing a new error with cagefs. When cagefs is disabled there were no errors ``` PHP Warning: SessionHandler::read(): open(/var/cpanel/php/sessions/eaxx/xxxx, O_RDWR) failed: No such file or directory (2) in /home/xxxx/public_html/system/library/session/native.php on line xxx ``` 0 -
I am facing a new error with cagefs. When cagefs is disabled there were no errors
Hello, In cPanel 64.0.7, the change was reverted for CloudLinux systems: Fixed case CPANEL-12314: Let cagefs handle management of /var/cpanel/php/sessions. CloudLinux is planning to handle this differently through a CageFS update. You can follow the CloudLinux blog to see when they publish the update: CloudLinux Blog Thank you.0
Please sign in to leave a comment.
Comments
35 comments