Uploads folder permission issue

The server guys created a new cpanel account to upgrade the WordPress instead of using the regular account.

That sounds a bit unusual.

Seems like it might be a file ownership issue. Is it possible that WordPress can’t write to the files because it isn’t running as the account that owns/created them?

@clayton

To me it’s quite usual for a Cpanel reseller account, as such you don’t have much rights to manage anything –> no rights to 755 or 777 file permission.
I work with a client with this exact problem with Cpanel as with simple “customer” rights, even if the guy upwards has a Quad Xeon on top :p

@wp_query

Following what I said to ClaytonJames, yes, sure it’s a matter of permission problems. On a coloc/shared server it seems it’s difficult to handle that with CPanel. But if you pay for quite a large server with this provider, I guess you can ask them to assign you a few dedicated IPs, with really root rights (not on full server, but root for LAMP server for this IP).

Because I guess your need is to downgrade to 755, which you can’t if not root…

Other option, and if your provider is just good, ask provider to downgrade your whole web folder to 755 (public_html and subfolders). Again it’s highly dependent on what setup you use. And, for a good secure setup, not all files shall be put to 755 chmod I know. Just a rough idea to help you quick fix. And real Linux/Sysop/WP pro will tell you what is necessary or not. I can tell most of WP files are ok in read only mode which is 644 (from Ubuntu LTS/Apache & Nginx tested hand-made servers).

Hope it helps,

@wp_query

When you get a moment, you might contact your hosts support group and ask them to make sure that all of your files and directories are actually owned by your user account. Installing or upgrading WordPress files as a different user account may have caused some ownership issues that could prevent WordPress from writing to your file structure as your own user account. I would be much more concerned about why a “new cPanel account” had to be made in order to complete the WordPress upgrade in the first place. If you don’t (or can’t) have full ownership and control over the files on your own web space, then it’s time to find a new host who is better qualified to administer to the needs and safety considerations of a shared hosting environment.

Thank you @clayton and @digico. Your responses cleared a lot of our doubts.

We spoke to our host. They clarified that they tried to create a cpanel account but then went ahead and upgraded the wordpress manually as root. We are also using the PHP handler DSO. Do you have any idea of DSO not being able to handle the default folder and file permissions in the wordpress 4.3.1?

Thank you.

DSO means php is running as an Apache handler. File and folder permissions are all still valid, but you need to own or be in a group that owns the files in order to change the permissions – or write to them.

They clarified that they tried to create a cpanel account but then went ahead and upgraded the wordpress manually as root.

That could be a genuine concern. None of the files on your web space should be owned by root.

Are you in a shared hosting environment?

[edit] Some good general info – Permission Scheme for WordPress

Thank you @clayton.

Are you in a shared hosting environment?
No, we have a dedicated server and have root access.

None of the files inside wordpress and its sub folders are owned by root. Looks like there is no ownership issues. In spite of that, when we try uploading through media, the folder permission is expected to be 777. Even having the permission as 775 does not let us do make any uploads.

Looks like there is no ownership issues. In spite of that, when we try uploading through media, the folder permission is expected to be 777.

My best guess would be that because php is running as an apache module, the files are being written as the user the web server is running as: apache, www-data, nobody, etc.. (depending on how you configured the server)

Take a look at the /wp-content directory, then look at the /wp-content/uploads directory and compare the ownership settings. I’m going to guess that unless someone has already manually changed the ownership, /wp-content may be user:user, and /uploads may be owned completely by apache:apache (or whatever the web server runs as). The web server can’t write to the /wp-content directory because your user account doesn’t belong to any group that the web server is running under. If /wp-content is owned username:username, then WordPress just plain doesn’t have permission to write to that directory. That could be why 775 won’t work, but 777 will.

Just guessing, mind you.

@clayton, thank you again for your response.

I compared /wp-content and /wp-content/uploads directories for the ownership settings. Both are owned by cpanel user account only. The folder permissions are also 755.
Only for the current uploads since (october, post WP version upgrade), the permissions for the monthly folders within /wp-content/uploads/2015 has been changed to 777 and hence the ownership ‘nobody’.

Re: what user the webserver is running as, I am trying to find out from my host. If that is going to be different (apache, www-data,etc.) not as cpanel user like you pointed out, then I guess we have cracked the issue ??

But my point is, we have always been using DSO, hence PHP should have been running as apache module right from day 1. Apache/Webserver user could not have changed recently. So I am failing to understand how it turns out to be an issue since the last couple of months since doing an upgrade?

Before october (ie. upgrade), we had the monthly folders within /wp-content/uploads/2015 with 755 permissions only and we were able to upload files from the media.

But my point is, we have always been using DSO…
…I am failing to understand how it turns out to be an issue since the last couple of months since doing an upgrade?

I don’t think it changed after the upgrade. I think the condition existed prior to your upgrade. I can say with a relatively high degree of confidence that:

A) The condition probably existed prior to your upgrade to 4.3.1.

“We recently made an upgrade to WordPress to 4.3.1. The server guys created a new cpanel account to upgrade the WordPress instead of using the regular account.”

That tells me there was a problem before the upgrade took place, otherwise the upgrade would have gone smoothly from your dashboard.

B) WordPress will not change file and folder permissions, and it won’t change file or directory ownership.

C) You have a server configuration issue rather than a WordPress issue. You will need to have whoever is responsible for your server administration sort out what might have changed on the server prior to your 4.3.1 upgrade attempt.

@all, hello and message for wp_query

@all
I think we must all move to full WP 4.4, for me it’s easy but I don’t have clients using large amounts of WP heavily cusomized queries for now. So like we say in french, “easier said than done”.

@clayton
Frankly, I’m more and more disgusted with CPanel, as it’s seems ok for general stuff like drupal, but not for WP. On a general fashion, Cpanel does avoid updates for WP and ssl. I’ll advise you to take on a full dedicated server if you work with Cpanel. Because it’s far from giving control on coloc or so servers.

@digico Paris

…disgusted with CPanel, as it’s seems ok for general stuff like drupal, but not for WP. On a general fashion, Cpanel does avoid updates for WP and ssl. I’ll advise you to take on a full dedicated server if you work with Cpanel.

Those statements are waayyyyyy to subjective (if not entirely incorrect) to form any negative conclusions about cPanel. It may be that way in your experience, but mine indicates that the greatest majority of “problems with cPanel” seem to present themselves due to a lack of user understanding or experience – and of course that doesn’t take into account re-sellers or hosts who may not have a clue what they’re doing.

I think we must all move to full WP 4.4,

I think that is the general idea already, simply because all previous versions of WordPress become unsupported after a new release.

“None of these are safe to use, except the latest in the 4.4 series, which is actively maintained.”

I think anyone who pays attention to security and updates has probably already considered that. It’s a good idea.

@clayton James

I found out answers to some of the questions you pointed out previously.

1. DSO is running Apache as “nobody” user. But since /wp-content/uploads/ is owned by cPanel user, it isn’t possible to update with 755/775 permissions. Requires 777 permission.

2. My host is recommending to change to FCGI handler, which they say will allow Apache to run as cPanel user. But I’m hesitant to change handler since not sure what kind of compatibility issues will start throwing up. What would you recommend?

3. We have a similar environment that we use as dev environment set up using another cPanel account. I tried comparing the Folder/File permissions and ownership of WP folders there Vs. in our live environment.
We have “cPanel-user:nobody” as the ownership for all WP folders, subfolders and files. The permissions are 774 for all the folders and 664 for all the files. There we are able to upload files because of the “nobody” group.
Is 774 permission with “nobody” group better than having 777 permission?
May be I should do the similar permission and group in our live environment?

Thank you for your time and response.

I’m not comfortable with coming right out and suggesting to you what users and permissions you should apply to /wp-content, its sub-directories, and files on a production server that I really have no knowledge about other than what we’ve already discussed.

DSO is running Apache as “nobody” user. But since /wp-content/uploads/ is owned by cPanel user,

I will however refer you back to this information: “Any file that needs write access from WordPress should be owned or group-owned by the user account used by the WordPress (which may be different than the server account). For example, you may have a user account that lets you FTP files back and forth to your server, but your server itself may run using a separate user, in a separate usergroup, such as dhapache or nobody. If WordPress is running as the FTP account, that account needs to have write access, i.e., be the owner of the files, or belong to a group that has write access. In the latter case, that would mean permissions are set more permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644). “ Source: Permission Scheme for WordPress

Whoever is helping you manage your server should be able to quickly spot what changes are necessary if you decide to continue using PHP as an apache module.

@claytonjames,

Whoever is helping you manage your server should be able to quickly spot what changes are necessary if you decide to continue using PHP as an apache module.

I am asking again the question I had for you earlier w.r.t. to using PHP as an apache module.

Would you recommend switching to FCGI handler instead of DSO handler?

My host tells me FCGI handler will allow apache to run as a cPanel user (unlike DSO that runs apache as a nobody user).

Would you recommend switching to FCGI handler instead of DSO handler?

Yes.