At some point in your WordPress admin career and ESPECIALLY if you are in the business of migrating websites from one server to another you will EVENTUALLY encounter this error message when attempting to add images to your media library:
“<image-name> has failed to upload due to an error. The uploaded file could not be moved to wp-content/rest-of-path-here”
An additional side effect of this same error is that fact that you are NOT able to automatically update existing plugins OR add new ones. When you try to add a new plugin (for example), WordPress will gracefully present you with an FTP credentials screen so that you can manually upload the new plugin. So…..
WHY IS THIS HAPPENING?
In MOST instances, (especially in the case of a MIGRATED website which was already running without issues on another webserver) what is happening is that WordPress passes off the FETCHING (or uploading) of the requested image to the web server process on which your website resides and it happily retrieves the image.jpg from your harddrive and uploads to temporary memory of the server THEN tries to commit the file into storage of the WordPress media library (which is most often /wp-content/uploads/<year>/<mo>). This of course is where the error occurs. The account that actually RETRIEVES the file from your computer is the Apache service account and many times the NOBODY account (yes, that IS the real name of the account) on the server itself. Since that particular account has NO OWNERSHIP or rights to the /wp-content/uploads/<year>/<mo> folder… you get the nice error message indicating there was an issue placing the image in that particular folder. THIS IS BY DESIGN PEOPLE… and it means your web server is simply enforcing the security parameters it is aware of…. Which is a good thing!
SOME REALLY BAD ADVICE
So like any other good WordPress admin and to try and resolve this issue, you copy – paste – and Google. What you will find however should not only SHOCK you but should make the hair on your security-conscience neck stand up! 9 out of 10 “recommendations” on how to resolve this problem involve setting the permissions on your /wp-content/uploads folder to 777!!! … to that I say NO – NO – NO! If you’re going to do that you might as well change the password to your “admin” account to 12345 as well!
SO LETS INSTEAD ACTUALLY FIX THE ISSUE… THE PROPER WAY
STEP 1: Find out which account on your server is the Apache Service Account – Unfortunately, this part is not always easy for those with a shared hosting account and NO shell (sometimes called SSH) access to their site. UPDATE: See the link provided below by jervisbay in the comments section on how to fix this issue in a shared hosting environment. Thx jervisbay! The intimidation factor is that shell access is a basic command line interface… you know, the old black screen with white text and a command prompt… YUCK! However, if you DON’T have this type of access… just email your hosting support team with this simple question…What is the name of my website’s Apache Service Account? You might also want to say in your email that you are trying to set the proper permissions on your WordPress installation and that should help give them some context as to your request.
Now… if you DO have shell access to your website go ahead and login using a shell program like Putty (our favorite). If you are on a VPS or Reseller server, you will likely have access using the <root> user which IS preferred. For shared servers, you will likely NOT have shell access and will instead have to send a support email.
NOTE: The instructions below are only for Reseller, VPS, and Dedicated server environments. The reason being is that we are granting access to a SERVICE running globally on these machine types. This is NOT something you’d want to do in a SHARED hosting environment because obviously it would open you up to a whole new set of security concerns.
However to get around this, shared hosting environments implement a technique called “suexec” which abstracts the account access yet gives proper rights to enable functionality to work as it should. SUEXEC is a topic for another blog post discussion, but you might want to mention it in your support email (should you go that route). As a matter of fact, here’s a pretty hearty discussion on the topic which you might enjoy.
Once logged in as root, execute this command:
ps aux | egrep ‘(apache|httpd)’
This should return output (and a list) like the following:
root 5597 0.0 0.1 70904 6552 ? Ss Nov18 2:03 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8715 0.0 0.0 69728 2516 ? S 17:11 0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8717 0.0 0.0 70904 2608 ? S 17:11 0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8718 0.1 0.4 1332864 17180 ? Sl 17:11 0:06 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8719 0.1 0.4 1333004 17012 ? Sl 17:11 0:07 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8720 0.1 0.4 1333356 16828 ? Sl 17:11 0:07 /usr/local/apache/bin/httpd -k start -DSSL
nobody 8808 0.1 0.4 1333584 16088 ? Sl 17:12 0:06 /usr/local/apache/bin/httpd -k start -DSSL
nobody 11467 0.1 0.2 1332816 11696 ? Sl 18:51 0:00 /usr/local/apache/bin/httpd -k start -DSSL
root 11611 0.0 0.0 4052 188 pts/0 D+ 18:56 0:00 egrep (apache|httpd)
The account name of nobody (highlighted in black above) indicates that THIS is my apache service account and the one I should grant access to my entire WordPress files in order for life to be good once again.
STEP 2: Grant this user rights to the WordPress install – This process is quite simple… just execute the following command within your shell windows:
chown -R nobody /home/<username>/public_html
This of course assumes that the root of your WordPress installation is within the public_html folder (quite standard on most all CPanel / Linux installations). What this command does is it starts at the root path of WordPress and grants the user called nobody with ownership rights on ALL files and folders RECURSIVELY (meaning it includes sub-folders and files within sub-folders as well) throughout the site.
PROBLEM SOLVED!
So that should do it! Now go back to your WordPress admin control panel and attempt your image upload to the media library once again. You should find that all works without issue (as in the image below). Also, you will now be able to automatically update and upgrade plugins within the site.
Comments (99)
January 8, 2015 at 8:17 am
Thank you! I’ve been searching for about an hour through many clueless suggestions to change from 755 to 777.
January 24, 2015 at 3:22 am
No prob Leo… Glad to help!
March 5, 2015 at 1:13 pm
Very helpful for wanna be server admins like myself! Thanks!
March 12, 2015 at 4:56 pm
Glad to help Jacob!
April 8, 2015 at 11:07 am
This is great! Thanks for taking the time to post a detailed explanation of the problem and also a way to avoid creating security issues. It’s helpful for me to know the root of a problem so that I will remember how to fix in the future rather than just doing a quick fix.
April 13, 2015 at 5:14 pm
No problem at all…obviously having to figure this issue out for myself hopefully helps others from having to “pull their hair out” =0)
April 11, 2015 at 10:32 am
Hi Todd,
I had this problem and tried your method but unfortunately it didn’t solve the problem for me.
I then found this answer on Stackoverflow: http://stackoverflow.com/a/28030042/2178549.
I typed in the chown command as in your Step 2 but with the FTP user instead of the user that runs the appache2 process. Now I can upload images.
Cheers,
April 13, 2015 at 5:13 pm
AWESOME!… thx so much for the tip. Glad it worked for you
June 24, 2015 at 3:08 pm
So the solution there seems to be to just change the permissions for the wp-content folder to 775? That didn’t do anything for me. Not sure if that was the actual solution or not, but i still can’t get this to work.
June 25, 2015 at 1:42 am
Hello Marianne, In a shared hosting environment, I would just email support and ask 1) what group(s) is your FTP user account member of and 2) does that user and/or group (by default) have full write access to the root of your wordpress install and all sub-folders, files below it.
Then I would simply close the post with the error message you are receiving and suggest that the account does NOT have sufficient rights.
Unfortunately in shared hosting environments, you’re at the mercy of their config settings =0(
April 13, 2015 at 6:54 am
Hope google will index this page as fast as he can.
Really annoyed to read about permission changes to 777.
Thanks a lot Todd, you made my day.
Cheers
April 13, 2015 at 5:11 pm
Hey no problem…Glad to help!
April 22, 2015 at 7:54 am
Hello – this seems like the solution I am looking for. When I run the first command the response I get seems to indicate that the service name is ‘apache’ rather than nobody which is what I’ve used. When I enter the second string of commands I get the response ‘no such file or directory’. I have changed to the actual username on my site which shows up in the last line of the shell terminal and still no luck I have also ran it as . Any suggestions…?
May 29, 2015 at 2:32 am
Hello Bill, you likely have a different path to your files than the sample one I’ve given. Do you have cpanel access? If so, go into the file manager and navigate to the root folder of your site. There, you should be able to see the FULL path in the top-left directory listing in the File Manager window. Hope that helps!
April 29, 2015 at 1:53 pm
Changing ownership of all the files to apache could cause problems with modifying them later, unless someone is in the sudo group. I changed group ownership, rather than file ownership, to the apache user for the wp-uploads directory, and that should take care of it.
May 29, 2015 at 2:22 am
Excellent tip Krista!… thx!
May 11, 2015 at 3:49 pm
Hi Todd.
Thanks for posting this. Hope it moves up the Google rankings so all the “chmod 777” suggestions will go by the wayside. So I’m obviously here because I was having an upload problem as well. Unfortunately your suggestions didn’t help me, because my problem was with SELinux. I have solved that problem, and thought I would share.
If you are running WordPress and SELinux, the security context of the upload directory will likely be wrong, and that will cause SELinux to block any file uploads by WordPress. If you have SELinux enabled, all your web files will have to have a context of httpd_sys_content_t or else Apache won’t be able to even READ them. However, it still won’t be able to write them. The /uploads/ directory and the wp-config.php both need to have a context of httpd_sys_rw_content_t. Here’s how to do that:
chcon -Rv –type=httpd_sys_rw_content_t /path/to/html/wp-content/uploads
chcon -v –type=httpd_sys_rw_content_t /path/to/html/wp-config.php
You can see your changed contexts now by doing “ls -Z” in their respective directories.
Hope this helps someone else…
Thanks again!
Mike
May 29, 2015 at 2:22 am
Wow Mike… Thanks for the detailed follow-up! I personally do not yet have sufficient experience with SELinux (mostly standard CentOS 6), but I really want to dive deep as it is considered to be a Government-Grade linux distro!
August 17, 2016 at 7:27 am
Thanks for your help ! It’s working now !
May 26, 2015 at 6:18 pm
So I did this and it totally worked, but I messed up and gave apache user ownership of entire public_html folder instead of just wp files. Any hints on how to correct this would be welcome and appreciated. Thanks!
May 29, 2015 at 2:47 am
Austyn, so long as your website is the only files in the public_html you should be fine. If that’s not the case you will need to have an idea of what the permission settings were BEFORE and then we can enter commands to reverse the settings. THEN… we would need to set the permissions on the proper folder which contains ONLY your site’s files. Just let me know what you find out and we can go from there.
June 2, 2015 at 2:44 pm
Oh thank you for the follow up! Ok, not sure if it makes a difference, but my public_html directory is actually httpdocs. Anyways, there were some non WP related things in there, such as a folder of images from before WP was installed. My first error was that WP not in it’s own folder to begin with. It was installed directly in httpdocs, so all the core files were floating around in there, rather than neatly tucked away in their own directory.
The main issue I’m having is that I no longer have ftp access to the httpdocs folder. I get 2 errors: “permission denied” and “failed to retrieve directory listing” when I attempt to open that directory.
As to what the permissions were BEFORE, I think the folder permissions were the same… (unless that’s not possible). I know who the owner was before… Sorry I’m not very savvy with this sort of thing, so I’m not sure if I’m answering your question or not…
Thanks for your help!
June 8, 2015 at 5:16 pm
Austyn, hm…. that can be a bit of a tricky situation. Are you on a shared hosting environment? If so, the FIRST thing I would do is perform a COMPLETE backup of both the files in httpdocs AND your website database in MySQL. Next, inquire with your hosting company if they can reset all permissions to default. Then you start there and re-apply the permission settings as outlined in Jervisbay’s comment for shared hosting environments. I know its a bit of surgery, but there’s no other elegant solution. The MAIN factor is to ensure a good backup of both files and the database… that IS YOUR SAFETY NET.
If you are instead running on a VPS or dedicated server, you can likely reset the permissions on your own via a secure shell (SSH) session so long as you have root login credentials. Hope this helps!
June 4, 2015 at 8:52 am
Thanks a lot!
July 1, 2015 at 5:14 pm
Thank you for your elaborate explanation. I’m experiencing the same problem with a site I’m making for a good friend. The thing is, the problem only occurred recently: one moment I’m perfectly fine, and the other moment it’s impossible to add more media files (or through plugins such as nexgen gallery). I’m still not sure how this happened. Any suggestions?
I’m not a true web designer, just a guy with a passion. I want to try your solution, but step 2 somewhat confuses me. Where/ how can I execute the suggested command-line? (you state that I should put it in the shell windows, but you stated in step 1 that not all users have shell access). With some extra information I might be able to continue building the site.
Could a re-install of wordpress help?
July 22, 2015 at 11:28 am
Theo, let me share a little something that I found out recently as well… this issue can often be the result of a website infection (which is MORE common than not). If someone has obtained access to your site, they have likely changed file/folder permissions based on their needs to deploy their virus files. I would HIGHLY recommend doing the following: 1) download ONLY the wp-admin and wp-includes folders in their entirety 2) now go and download the standard WordPress install which matches EXACTLY the version you have. 3) Now use this free software: https://sourcegear.com/diffmerge/ to compare the 2 folders (one version from your website and one from the default WP install). If your site is NOT infected, there will be no to few differences between the folders. If the results show lots of questionable files, then you are likely infected and must clean that up before feeling confident that you can move forard.
Obviously you will want to LOCKDOWN tight the security on your site as well.
Hope that helps!
July 3, 2015 at 12:34 am
Awesome! I knew it would be something like this, but just needed your insights and I was all sorted! Thank you for sharing
July 22, 2015 at 11:22 am
Matt, No prob at all… glad to help!
October 7, 2015 at 11:04 am
finally someone who knows what they are doing.. been searching for ages thank u so much
October 7, 2015 at 7:41 pm
Thanks for the kind words Storm… Glad to help!
October 16, 2015 at 11:14 am
also to make the tutorial a little more noob friendly if you change your quotes to a regular utf8 ‘ people will be able to copy and paste it
December 26, 2015 at 2:05 am
Thx for the heads up… actually we’re launching a NEW site soon which will resolve this small issue.
October 16, 2015 at 11:15 am
Looks like your formatter automatically converts the quotes :/
October 21, 2015 at 9:51 pm
I tried using putty with the command you suggested and get this error –> -bash: syntax error near unexpected token `(‘
This issue is weird as i have my own box and it worked then literally 9 mins later it did not
December 26, 2015 at 2:04 am
Can you paste the EXACT command you’re trying here and I’ll have a look
December 19, 2015 at 2:36 am
Thanks this was a big help. But I now notice that if I go into cpanel’s file manager, my public_html directory shows up as blank even though it is obviously full of files/content/etc. Website works fine except for this issue. Any ideas on a fix?
December 26, 2015 at 2:03 am
Great! Glad to help. Did you try clearing your browser’s cache?
January 7, 2016 at 1:32 pm
HI Todd,
I am a relative newcomer to wordpress and have succeeded in updating the site to wordpress 4.4.1. However, during the update I had some setbacks which I was able to resolve within a day. Now I have this issue with uploading images :/. Considering that I have a godaddy hosting site and I know relatively little. Can you explain to me how I can go about fixing this problem by gaining shell? access through godaddy?
March 17, 2016 at 1:38 pm
Sam, unfortunately if your on a Shared hosting acct with CrapDaddy you will NOT be able to gain shell access. However a VPS or dedicated account will give you this!
January 29, 2016 at 8:33 am
One small thing that you also need to check is that is your Server full? i noticed that one of my clients get this message and started to tackle problem it was so obvious that i did t see it first. Just add more space or delete old. Thing was that Her server used to fill via email.
March 17, 2016 at 1:37 pm
Ahh… great catch Lauri! Especially on Shared hosting accts where disk space may be limited.
March 3, 2016 at 3:41 pm
Very userful sensible article that cuts through the clamor of Media upload issues & gets straight to the issue. Glad to have spotted yours.
Thanks much.
March 17, 2016 at 1:36 pm
Glad to help!!
March 13, 2016 at 5:05 am
Worked perfectly! Thanks Todd!
March 17, 2016 at 1:36 pm
Your quite welcome Shad!
May 3, 2016 at 5:18 pm
omfg, I should have known this but damnit THANK YOU! I had been changing owners between root to the site owner name etc… phew glad this is sorted have been working on it for weeks.
February 2, 2017 at 12:19 pm
That’s good news Melanie!
July 9, 2016 at 10:26 am
Thank you!!!!!!!!!!!!!!!!!!!!!!!! God bless
February 2, 2017 at 12:18 pm
Your quite welcome Ernesto!
July 25, 2016 at 11:34 am
I’ve migrated hundreds of sites and have not come across this yet but its good to know. After testing various migration plugins, I have been using Updraft Plus for migrations for several years (i have no association with them) with a 95% success rate. Manually I use SSH or cpanel backup and restore.
February 2, 2017 at 12:18 pm
Great to know… personally we use BackWPUp which is similar to updraft plus.
August 28, 2016 at 2:41 pm
For those of you who are new to LAMP installations (Linux – Apache – MySQL – PHP), Apache2’s username is different than nobody. My installation came up as www-data.
When you run ps aux | egrep ‘(apache|httpd)’, confirm the user exists by running cut -d: -f1 /etc/passwd
then chown -R (Username) /location_here
Took me a few hours to figure this out, I’m new to moving wordpress, this is something wordpress should address before you move sites. Should be a test application you can throw up, simple checks.
February 2, 2017 at 12:17 pm
That’s an excellent point Thomas, and is true in some cases. Just depends on how the hosting company setup the apache user credentials during setup.
September 15, 2016 at 3:14 am
For me running XAMPP on OSX localhost, it turned out to be daemon. Thanks. This really helped me solve this problem.
February 2, 2017 at 12:15 pm
That’s really good news!
October 5, 2016 at 4:39 am
You sir, are a god.
February 2, 2017 at 12:15 pm
=0) … well I wouldn’t go that far… glad to help!
November 3, 2016 at 9:18 pm
I then found this answer on Stackoverflow: http://stackoverflow.com/a/28030042/2178549.
I typed in the chown command as in your Step 2 but with the FTP user instead of the user that runs the appache2 process. Now I can upload images.
February 2, 2017 at 12:14 pm
That’s great news!
November 8, 2016 at 1:28 pm
Thanks. I had little idea what the problem was so I googled it and hit your page here. Just a glance at this and I knew the first thing to try would be to recursively set the group (ownership) of wp-content to www-data (it’s an Ubuntu server). That worked perfect. No changing of modes needed.
February 2, 2017 at 12:09 pm
SWEEET! Glen…
November 30, 2016 at 8:05 pm
Todd, I can’t thank you enough for this post. Tried many methods after moving to a VPS and they were all dead ends. This worked like a charm!
February 2, 2017 at 12:09 pm
Awesome Pat! That’s excellent news!
December 1, 2016 at 2:12 pm
Yet another thank you. It made a change to be able to do something properly instead of the horrible 777 workaround.
February 2, 2017 at 12:08 pm
Great!!!
December 7, 2016 at 3:18 pm
I searched everywhere for this answer. Thank you! I have a new problem now though… maybe you can provide insight.
VPS has been running for more than 2 years flawlessly. To test some jsp, I needed Tomcat installed. The first mistake I made was installing Tomcat (EasyApache) onto the server myself. I am not a server admin and should have had someone else (aka more knowledgeable than I) do this. Such is life… it was done.
After installing Tomcat, ALL WP sites lost upload / update / execute privileges. It took me a few days and your message here, to correct that. Thanks again.
Now however, when I login to a cpanel, my public_html folders appear empty. I can see no files anywhere. Outside the public_html, I see files fine. Inside… nothing, nada, blank. The websites however are running without a hitch, I just can’t see the files in cPanel.
Any suggestions?
Mark
February 2, 2017 at 12:08 pm
Mark, sorry but I’m not sure about Tomcat but I suspect it uses a different path than public_html for the root of websites and likely it has moved the files? Look for something like httpddocs… I’ve seen that folder structure in the past. Best of luck!
December 8, 2016 at 6:10 pm
Hello Todd,
I am having a bit of an issue with this command, based on the comments I know it is something I am doing wrong, I enter in the following
ps aux | egrep `(apache|httpd)`
but I get the following back.
bash: ps: command not found
bash: apache: command not found
bash: httpd: command not found
Usage: egrep [OPTION]… PATTERN [FILE]…
Try `egrep –help’ for more information.
I am using shell direct and know i am on the root.
Any ideas?
February 2, 2017 at 12:06 pm
Owen, try entering “sudo” (without double quotes, used here to highlight what you should type) and see if that works. The sudo command forces the command interpreter to run AS root (if permissions are allowed).
December 11, 2016 at 6:26 am
Thank you! Finally solve the problem
February 2, 2017 at 12:03 pm
That’s GREAT news Adrian!
December 15, 2016 at 10:58 am
Thank you so much! This worked when nothing else did. I called my host (Lunarpages) and emailed them the link and they did it for me. The tech didn’t know about this fix, either.
February 2, 2017 at 12:03 pm
AWESOME! Glad it helped!
February 16, 2017 at 5:30 am
Hi Tod,
I like the way you think, finally someone not blindly suggesting to change perms to 777.
However: we’re the hosting party in my scenario.
On a plesk environment, we often install wordpress and create a website through that, never had any owner or right issues.
Now we have a hosting for a customer, who created the wordpress site outside of our hosting and migrated it back through a backup/restore plugin. We saw all files had the www-data (apache) user applied to it (as well as that usergroup). With that, neither fps or file manager worked anymore. I’ve changed file and directory ownership back to the system user of that domain (as all other domains have) and group psacln. On httpdocs (root), i’ve set the psaserv group.
The issue we’re having is exactly as you describe: unable to upload media items and issues with plugins. I’ve verified all rights with working setups, all the same or even more permissions. Your suggestion is what we had before I had to change rights, so we cannot apply this.
Something curious though: when I tried enable wordpress logging, I need to give “other” rights on the wp-content folder, so apache could write my log file there.
As my other setups don’t explicitly need rights for apache, what could be causing this?
Any insights would be welcome.
February 17, 2017 at 2:04 am
What a legend thank you so much!
February 17, 2017 at 8:41 am
“9 out of 10 “recommendations” on how to resolve this problem involve setting the permissions on your /wp-content/uploads folder to 777!!! … to that I say NO – NO – NO! If you’re going to do that you might as well change the password to your “admin” account to 12345 as well!”
Thank you so much!! I now have my server working flawlessly and my keyboard soaking wet with my coffee as I laughed so hard to the 12345 tip hahahahahahaha
March 21, 2017 at 10:45 am
I encountered exactly the same problem however after some help from my hosting company and showing them this page, they identified that the upload path in the database of the website was not correct. I (the plugin i used) had not updated the url.
I cannot say if this will be the case for everyone but it is certainly worth a look into first.
Thank you
Alex
March 24, 2017 at 4:26 am
Worked perfectly thanks!
Need to login as root though.
April 23, 2017 at 8:51 pm
thank you so much, nice explanation.
i fixed the issue just by
chown -R www-data:www-data /var/www/…/uploads.
June 29, 2017 at 6:46 am
Hey Todd.
I was facing a similar issue but a colleagueof mine is having different thoughts on the upload process.
Now I want to get have a better understanding of the file upload process.
My colleagueis says that in the whole process (on our ubuntu server) there is no “nobody” account as apache was installed under “root”.
Also he says php is picking up the file from a temp folder and moves it to the upload folder.
If I understand your post correctly it isn’t php moving the file from a temp folder but apache.
The thing is dat the our wordpress install was switched to a multisite.
After which I could not upload files anymore.
These folders in the “uploads” directory automatically get the root user set to them (probably because everything was installed as root) but my colleague just changed the user from “root” to “www-data” and now everything works again.
Is this a good solution or should it still be done like you describe in your post (even though old by this point.)
Hope you still read this and hope you can help me out a bit.
Kind regards!
August 30, 2017 at 12:53 pm
I wish I could help but I have very little experience in WP multi-site and how it handles file permissions. Sorry…
September 20, 2017 at 10:11 pm
is it too gay to say i wanna kiss you for this help??
October 19, 2017 at 5:17 pm
Not gay at all… =0) Glad to have helped Rodrigo!
October 6, 2017 at 2:44 pm
I have recently experienced this issue and noticed that the solution above is for C panel users. Can someone offer assistance for Plesk users?
October 19, 2017 at 5:13 pm
OMG!! I was searching for two entire days how to fix this error (and some others caused by the same kind of issue) in most recent sites (because of WordPress updates) but I don’t wanted to change permissions to 777; in one of all the tons of articles I was reading they said it could be some Apache php.init conflicts but they don’t tell how to fix it. Actually I fixed the issue following all the explanation in your post, but in the server I’m using there’s no NOBODY user, it is called APACHE and I just changed the username in the command and everything was fixed!
Thank you SO much for this info.
October 19, 2017 at 5:16 pm
Glad to have helped!
October 26, 2017 at 4:00 pm
My friend you are a life saver, i am not well versed in the ssh command console but your explanation was great and easy to follow, thanks so much!
December 27, 2017 at 1:20 pm
OMG, that was verry helpful to me thank you so much
cn arabia
January 6, 2018 at 6:59 pm
You’re quite welcome… glad to help!
January 16, 2018 at 4:58 pm
Thanks for this tip. My hosting company was clueless as to how to fix it. This did the trick!!
January 16, 2018 at 5:21 pm
That’s great Shawn! So glad to help!
January 18, 2018 at 5:38 pm
Okay, so this worked to fix my issue with WordPress, but now I’ve lost ftp access for the account owner of the cPanel. Any thoughts as to why this would happen?
Thank you so much for your help.
February 13, 2018 at 10:32 am
Hey Shawn… hard to tell but my guess would be that you have a DIFFERENT user account (other than the default) being used by the apache service… check with your hosting provider and ask them specifically for the apache user account & group… that should do it.
February 9, 2018 at 6:48 am
Hello, I just wanted to say thank you for this blog post. It really helped. My issue was on uploading files on Cent OS 7 with SELinux.
I had to run sudo chcon -t httpd_sys_rw_content_t /data/www/html/sites/mysite/uploads -R in order to enabled read/write/delete permissions to my upload folder as SELinux was preventing it from doing anything even if I follwed the steps in this thread.
Thank you very much Todd and Mike!
February 13, 2018 at 10:30 am
That’s great Vic! … and thank YOU for the SELinux command line…
February 11, 2018 at 3:54 am
The voice of sanity!
After reading so many “expert” fixes, your tip was the ONLY one that worked first time for me. Nice,simple and straight to the point!
Thanks
February 13, 2018 at 10:29 am
Awesome Ron!… glad to have helped you.
February 18, 2018 at 10:25 am
Hi, thanks for your great article, but do you know how to fix this on local? My site is offline, I used xampp / desktopserver to create it. I think it was after a windows refresh that it messed up
Thanks in advance
April 11, 2018 at 12:20 pm
Hello Mari-Claire, steps are exactly the same. xampp is a localized version of a web server stack utilizing all the same commands. You simply need access to the shell of the server in order to execute the commands as outlined.
Hope it helps!