How to fix “The uploaded file could not be moved to wp-content” error message

WordPress the uploaded file could not be moved to wp-content

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…..


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!

the uploaded file could not be moved to wp-content error message


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!


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.

the uploaded file could not be moved to wp-content success


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 (44)

  1. Leo - Reply

    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.

    • Todd - Reply

      January 24, 2015 at 3:22 am

      No prob Leo… Glad to help!

  2. Jacob - Reply

    March 5, 2015 at 1:13 pm

    Very helpful for wanna be server admins like myself! Thanks!

    • Todd - Reply

      March 12, 2015 at 4:56 pm

      Glad to help Jacob!

  3. Taylor - Reply

    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.

    • Todd - Reply

      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)

  4. Jervisbay - Reply

    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:
    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.


    • Todd - Reply

      April 13, 2015 at 5:13 pm

      AWESOME!… thx so much for the tip. Glad it worked for you

    • Marianne - Reply

      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.

      • Todd - Reply

        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(

  5. Marco - Reply

    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.


    • Todd - Reply

      April 13, 2015 at 5:11 pm

      Hey no problem…Glad to help!

  6. Bill - Reply

    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…?

    • Todd - Reply

      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!

  7. Krista - Reply

    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.

    • Todd - Reply

      May 29, 2015 at 2:22 am

      Excellent tip Krista!… thx!

  8. Mike - Reply

    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!


    • Todd - Reply

      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!

  9. Austyn - Reply

    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!

    • Todd - Reply

      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.

      • Austyn - Reply

        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!

        • Todd - Reply

          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!

  10. Mike - Reply

    June 4, 2015 at 8:52 am

    Thanks a lot!

  11. Theo - Reply

    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?

    • Todd - Reply

      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: 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!

  12. Matt Woodward - Reply

    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 :)

    • Todd - Reply

      July 22, 2015 at 11:22 am

      Matt, No prob at all… glad to help!

  13. Storm - Reply

    October 7, 2015 at 11:04 am

    finally someone who knows what they are doing.. been searching for ages thank u so much

    • Todd - Reply

      October 7, 2015 at 7:41 pm

      Thanks for the kind words Storm… Glad to help!

  14. Storm - Reply

    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

    • Todd - Reply

      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.

  15. Storm - Reply

    October 16, 2015 at 11:15 am

    Looks like your formatter automatically converts the quotes :/

  16. Sean - Reply

    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

    • Todd - Reply

      December 26, 2015 at 2:04 am

      Can you paste the EXACT command you’re trying here and I’ll have a look

  17. Matt - Reply

    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?

    • Todd - Reply

      December 26, 2015 at 2:03 am

      Great! Glad to help. Did you try clearing your browser’s cache?

  18. Sam - Reply

    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?

    • Todd - Reply

      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!

  19. Lauri - Reply

    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.

    • Todd - Reply

      March 17, 2016 at 1:37 pm

      Ahh… great catch Lauri! Especially on Shared hosting accts where disk space may be limited.

  20. Shanthini - Reply

    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.

    • Todd - Reply

      March 17, 2016 at 1:36 pm

      Glad to help!!

  21. Shad - Reply

    March 13, 2016 at 5:05 am

    Worked perfectly! Thanks Todd!

    • Todd - Reply

      March 17, 2016 at 1:36 pm

      Your quite welcome Shad!

Add a Comment