Websites report permission errors when trying to write/modify files

[kon33]

Hello,

I'm currently at 102.08 under CentOS 7.9.2009.

I'm having trouble with websites that use Wordpress, where they do not seem to able to write or modify existing files. I've been troubleshooting it, and the only way I managed to get things to work was to change the ownership of the whole directory tree (~/public_html/wp-content/uploads) to "username:nobody" and changing the permissions to 770. The files created in this form are always owned by nobody:nobody and with 660 permissions. Any other combination I've tried hasn't worked.

I found the following post that mentions a very similar issue, but it's related to PHP-FPM and it being disabled after an upgrade. My system currently has PHP-FPM enabled on all domains, so this didn't fix the issue for me.

SOLVED - Permission Error After Update

Hi, at 10.06.2021 04:00, my cPanel updated itself and then web sites working in hosting accounts started giving permission errors like "Permission denied in" etc. Nothing has been changed in server configurations/php etc. since 1 year and it was working fine until the update v96.0.9. When a...

forums.cpanel.net

Is there anything else I can try?

 

[cPRex]

Hey there! You mention "the files created in this form" - is this a web form on a certain page of your site? In general, if you upload content such as media files through WordPress, do those work as expected?

 

[kon33]

No, sorry, my bad. I meant files created by any upload mechanism while the directory tree's permissions are on 770 with "username:nobody" ownership, including media files through Wordpress.

If I leave the website with default permissions (650 for files, 750 for directories) and ownership (username:username) the files aren't uploaded, and I get an error message saying it has no write permissions.

 

[cPRex]

Are we sure that isn't the issue right there? I'd expect things to be 644/755, respectively.

 

[kon33]

What would the ownership be like? "username:nobody" or "username:username" ? Also, would the entire directory tree be 755?

 

[cPRex]

I expect everything to be username:username inside the public_html directory. All directories that will be available on the web would be 755.

 

[kon33]

Just tried changing the whole tree and files within it to the permissions and ownership you mentioned, it's now failing again with permission errors.

Is the public_html directory also supposed to be username:username? I just tried both ways (while the rest of the files remained as username:username and 644/755) and it still won't work.

 

[quietFinn]

public_html should be username:nobody, with permissions 750.

 

[kon33]

Yup, had it just like that. Still get permission errors.

 

[quietFinn]

What is the PHP Handler you use?

 

[kon33]

Where can I check that?

In MultiPHP Manager I have "PHP 7.4 (ea-php74)" as the default PHP version, with PHP-FPM enabled on all domains.

 

[quietFinn]

In the same page where you set the default PHP version and PHP-FPM you have list of PHP Handlers.

 

[cPRex]

public_html is also user:user

You're always welcome to submit a ticket to our team so we can check the interaction between the PHP handler and the permissions on the system directly.

 

[quietFinn]

public_html is also user:user

I checked that in a few servers and it's always user:nobody

 

[kon33]

In the same page where you set the default PHP version and PHP-FPM you have list of PHP Handlers.

Interesting. They all are on "cgi", no other PHP Handlers are installed (I'm guessing this is the reason I'm having this problem).

I see in your screenshot you have suphp. Is this provided by mod_suphp?

 

[cPRex]

Yes - you can change the handler to suPHP and that will likely resolve the issues.

 

[quietFinn]

Interesting. They all are on "cgi", no other PHP Handlers are installed (I'm guessing this is the reason I'm having this problem).

I see in your screenshot you have suphp. Is this provided by mod_suphp?

If you read here:

PHP Handlers | cPanel & WHM Documentation

PHP handlers contain libraries that the Apache web server uses to interpret and run PHP code.

docs.cpanel.net

The CGI handler executes PHP applications through the mod_cgi or the mod_cgid Apache modules. If you install the suEXEC module, the system executes PHP applications as the user that owns the VirtualHost that served the request. If you uninstall the suEXEC module, the system executes PHP applications as the nobody system user.

So yes, cgi without suEXEC is the problem.

EDIT - added this:
Yes, suPHP Is provided by mod_suphp

 

[kon33]

Good news, installing mod_suphp has fixed the problem.

Thanks everyone for the help.