• 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!
  • 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.

User Permissions / PHP / Files

KrazyBob

Regular Pleskian
Until I switched to Plesk 9 I had no trouble writing a log file for an application that I wrote. It used PHP's FOPEN() command. It would write the file as the user. Now it does jot write at all. If I run it manually it writes it as Apache:Apache. What's changed?

Code:
<?php
unlink('test.txt');
$fp = fopen('test.txt', 'w');
$date = strftime('%c');
fwrite($fp, $date);
fclose($fp);
?>

A similar block of code would write a ticker file that later would display on our pages. It was written and saved as the main site user, such as "siteadmin." No PHPnreports that it is unable to open or save the file. We've changed nothinhg. This script has run since 2002.

We worked around this by creating an external script and using a CRON to write the file and this works fine. This suggests that the user has permission to open and write the file! Imagine our confusion.
 
I am not able to duplicate this problem on my end if the file has the correct permissions.

Lets say test.txt is owned by user:psacln, by running a cronjob to write that file it will be successful. If you manually execute the script it will need to be owned by apache:apache. Another workaround will be to install suPHP so the webserver will run it under the same ownership as the file.
 
Back
Top