Posted in Security

WordPress : The uploaded file could not be moved to .

July 19, 2007 - 16 comments

If you get this message when trying to upload a file into wordpress admin area, this may mean that :

- the webserver doesn’t have the write permissions on the upload directory
- safe mode is enabled on the webserver

The easiest fix is to edit the value “safe_mode” to off in /etc/php.ini
YOU MAY NOT WANT TO DO THAT, THIS IS NOT SAFE

Read on..

What is safe mode ?

See http://be.php.net/features.safe-mode

Work-around to upload files with safe mode on :

See http://tiny3d.com/?p=35

Here’s the copy in case the link goes down

WordPress – File Upload Problems
Saturday 2nd September 2006, 0:49

When configuring WordPress to support file uploads I ran into a tricky issue. The server responded with:

The uploaded file could not be moved to .

The message above is displayed if there is a problem uploading or using the uploaded file, this is normally associated with security issues, such as the user that the webserver is running under doesn’t have write permission in the folder.

There is a thread on the wordpress site that discuss this issue. The most common cause for this problem is invalid directory permissions.

My problem however was not solved by changing the permissions of the folders. No matter what I tried it refused to work.

After turning to google I found out that this type of problems may also be caused by PHP being configured to run in SAFE MODE safe_mod=On in php.ini) which has the same effect as incorrect permissions. Php will refuse to read files that are not owned by the same user as the script being executed.

So by turning off safe mode (safe_mode=Off) the file uploads worked without problems… but personally I prefer running with safe mode enabled. So I needed to find another solution to allow file uploads even though safe mod is enabled..

It so happens that there is a related configuration option in php.ini. By setting safe_mode_gid=On safe mode checks the files GID (group) instead of the UID (user). When combining this with a sticky flag on the uploads folder (and it’s underlying year-folders if you have that option is enabled in wordpress) we can get file uploads to work properly even though safe mode is still enabled. Here is a list of what to do:

* Enable safe_mode_gid=On in php.ini
* chmod 7777 wp-content/uploads
* If the organisation option is enabled in wordpress, create one or more year folders and set chmod 7777 on them aswell.
* Restart the webserver so that the php.ini changes take effect.
* Try uploading a file.

Do not thank me, thank the original author at http://tiny3d.com

Comments

Tim Almond

August 29, 2007 - 0:45

Hi Sebastian,

Thanks for the tip.

Tim

Tim Almond » Blog Archive » Wordpress Upload Problem and Resolution

August 29, 2007 - 0:54

[...] Sebastien Wains solved my problem. If PHP safe mode is on (it checks user id that owns a file against the user reading it, I think), change it’s way of working to be group- instead of user-orientated. It worked for me. [...]

Pete S

December 27, 2007 - 4:35

G’day Sebastien. Thanks, that worked for me. I didn’t want to turn off safe-mode either. Some people seem to think it’s useless, but there isn’t a good substitute.

Yan

April 28, 2008 - 19:24

Pardon me if I were to ask you how do I enable safe_mode_gid=On in php.ini? And thank you.

Sébastien Wains

April 28, 2008 - 20:10

It depends on your system.

Under Debian Etch and Apache2 it is under /etc/php5/apache2/php.ini

Under RedHat systems, it is under /etc/php.ini as far as I remember

Yan

April 28, 2008 - 20:33

Thanks for the reply. But seriously I don’t even know a single thing about PHP, let alone edit it. Is there any simpler way for me to do it? I’m afraid I don’t even know where to dig that file. Anyway, thank you again.

Sébastien Wains

April 28, 2008 - 20:40

Sorry, there’s no simpler way (unless you have a provider with some kind of control panel). You should find a Linux knowledgeable person to help you on this issue.

Holly

October 19, 2008 - 21:49

hey thanks! worked for me!

Ruben Ortiz

November 29, 2008 - 12:52

Hi Sebastien, once again, thanks for the tip. The only thing I have not understand completely is the way you assign the permissions to folder with a sticky bit.

In theory, and if Im not wrong to assign sticky bit to a folder is with

chmod +t /whaetever

7777 is the same as +t ?

Thanks!

Sébastien Wains

December 8, 2008 - 23:14

7777 is suid, guid and sticky bit altogether

Kenneth

December 18, 2008 - 17:10

My wordpress website is hosted with a webhost. If i ask them to change safe_mode_gid=On, will they do it?

Ahmed Tawfik

March 14, 2009 - 17:25

nice explanation Sébastien Wains

Jasen G

July 10, 2009 - 22:56

I am having the same problem although my php.ini file looks like this:

file_uploads = On
upload_max_filesize = 80M
allow_url_fopen = On
post_max_size = 80M
memory_limit = 24M

should i make the memory limit larger to accommodate for more photos in a photoblog? or if that was the problem would i get an entirely different error?
thanks

Sébastien Wains

July 11, 2009 - 13:08

Can’t tell how WP implemented error message. “The upload file could not..” may be a generic error message for several errors. Check the code, this should help.

meds

April 26, 2010 - 8:02

I have the same experience. i have set uploads folder permission tho 777 but still eror.

and o ow, I found my disk is full.

Kiro

July 18, 2010 - 8:20

Hi,

I’m using WordPress 3.0 , and had the same problems yesterday, I’ve try to fixed it in every methods available from editing .htacess to chmod permission or even thought of editing php.ini.

But when i contact my server host, They said that ” wp-content/uploads ” ownership was “nobody”, and they have changed it back to my default main domain administrator, which was me myself.

Hope this is helpful to any wordpress 3.0 users who encounter this.

Leave Comment

Please consider visiting the partners below if you enjoyed this article :

If this post saved you time and money, please consider checking my Amazon wishlist.

Before submitting, some rules :
- Is your comment related to the article ?
- You're having a problem ? Have you checked Google, other howtos, docs, manpages ?
- You're still having the problem ? Have you raised log verbosity, checked traces, ran tcpdump ?
- Have you checked your configuratoin for typo ?
Unless your comment is providing additional info or respect the rules above, DON'T comment.
If you don't understand what you are doing, I urge you to read the documentation, I'm not your free Level 1 helpdesk guy.