• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue Plesk Auto Update broke PHP Session Directory

futureweb

Regular Pleskian
Hey there,
on all our Plesk Servers the latest Minor Auto Update (Plesk Onyx Version 17.8.11 Update #72, last updated on Nov 1, 2019 04:09 AM) broke PHP Session Directories.
Session Directories are configured according this KB: Session file folder in PHP is not auto cleaned

After the Update the chmod of the Directory was changed to 770 while it was 777 before ...

Before Update:
Code:
ll /var/lib/php/        
total 228
drwxrwxrwx 2 root apache 229376 Nov  1 00:02 session


After Update:
Code:
ll /var/lib/php/        
total 228
drwxrwx--- 2 root apache 229376 Nov  3 20:22 session

Resulting in PHP no longer able reading/writing Session Files ... Permission denied ...
chmodding it back to 777 fixed the issue ... but how to prevent this from happening in the Future again?

thx, bye from Austria
Andreas Schnederle-Wagner
 
Looks different by default on our systems:
drwx-wx-wt 2 root root 294912 Nov 10 12:40 session/
Not seeing the same issue.
 
On CentOS 7 it is indeed:
Code:
[user@server /]# ll /var/lib/php
total 12
  4 drwxr-xr-x  3 root root   4096 Nov  1 17:06 .
  4 drwxr-xr-x 37 root root   4096 Apr  6  2019 ..
  4 drwx-wx-wt  2 root root   4096 Nov 10 19:46 session

I'm not sure about CentOS 6 as we've migrated away a while ago, but in our old documentation I indeed see notes about the default being 770 and root:apache, with remarks about setting the access rights to 777...
 
Back
Top