Support » Fixing WordPress » Advanced problem – image upload

  • Hi,

    I’m not new to WordPress, PHP or MySQL, but I’m having a nightmare problem.

    I’ve moved my blog onto a dedicated Linux server. The transfer of the blog is fine. Everything is configured and working perfectly.

    However, when writing a post, trying to upload an image gives the error, “The uploaded file could not be moved to .”.

    Obviously the first thing I thought of was the folder permissions. All 755. Setting them to 777 DOES allow uploads to work, but for security reasons I am unhappy with such a workaround.

    I have been into the SQL and altered all instances of the absolute directory paths set by my previous server. I have verified PHP safe mode is off. There are no unusual settings in .htaccess.

    I’m am absolutely baffled as to what is causing this and of course how to fix it. I’m not prepared to use 777 as a solution for obvious security reasons. Could anyone shed any light on this issue?

    Since the 777 workaround does work, I am assuming that the problem lies within folder permissions somehow, though unrelated to standard CHMOD using FTP (or the server’s control panel, which I have also tried).

    Any help or suggestions welcome, even simple ones as I may have just overlooked something in the hectic mess that is server migration!

    Thank you.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Actually you should only have to chmod 777 the 1st time you upload. After that chmod 755 is supposed to work.
    Also, if you’re using FF and dragging and dropping the images, it’s a known FF bug. You’ll have to click on the image and “send to editor”.

    Yeah, I’d tried that several different ways. As soon as I revert back to 755 the uploads fail, giving the “The uploaded file could not be moved to .” error message.

    So they say, samboll. I’ve had exactly the same situation as louse101 – the uploads folder requires setting at 777 to allow uploads, forever apparently. I have one client who insists on doing things this way, and she’s signed a contract amendment that if her blog/server (not on MY space thankfully!) gets hacked, SHE is at fault, not I.

    I’ve heard of that here of course, V, but of all the installs I’ve done things work correctly. Better prepare myself for future grief, eh?

    I dunno…. all the installs I’ve done work “correctly” too – until you want to use the uploads function.

    And it’s NOT server specific. This is an entirely new host, different server, etc. – and it’s still not possible to change the uploads folder back to 755 and make it usable.

    Correct,vkaryl. I’m glad you understand the fix I’m in. Thanks also, samboll, though I think you must be wonderfully lucky!

    Curiously, uploads worked fine on my previous host. Because I did a manual migration (literally copying all web files from the old host to the new, then manually creating the DB to import the backup file into), I’m thinking that maybe something is set to work with my old server, and therefor is causing an error with my new one.

    Sadly a long set of Google searches prove only that most people are content with using 777, even in some cases in spite of warnings about security. Doesn’t help us! =(

    Would changing your web server to run suexec’d be an option?

    Not particularly. The site’s constantly in use. Are you not aware of any solutions that don’t require server swaps?

    A few sites I run were just hacked using the (wide open) /uploads/ folder (CHMOD 777).

    You can see if your site(s) have been hacked by using this very useful site. To see if your own domain (or IP) was hacked, put your own IP up in the URL at the end.

    I use Image Manager for image uploading and right there on the options page, Soderlind tells me something I should have read (and acted on) long ago.

    Base image directory

    The base image directory must be world writable i.e.: chmod 777
    Base image URL

    The URL to the base image directory, the web browser needs to be able to see it.

    Note that the directory can be protected via .htaccess on apache or directory permissions on IIS, check your web server documentation for further information on directory protection. If this directory has to be publicly accessible, remove scripting capabilities for this directory (i.e. disable PHP, Perl, CGI). We only want to store images in this directory and its subdirectories.

    On apache you can create the following .htaccess file in your base image directory:

    <Files ^(*.jpeg|*.jpg|*.png|*.gif)>
    		   order deny allow
    		   deny from all

    So at least then only images could be (hackingly) uploaded to your folder. I’m going to give it a shot.


    – Bradley

    Had some trouble with this, but found solution here.

    The key here is group privileges. The short answer is to use 770 privileges on wp-content and wp-content/uploads, and it will work securely, without any .htaccess mods.

    Here is a longer answer for interested Linux users.

    WP docs state “any file that needs write access from WordPress should be group-owned by the user account used by the webserver”. This is pretty terse – it gives you a big clue (but not all the details you need to understand WP file security on Linux).

    Here is a fuller explanation.

    If you know what 777, 755 etc mean, skip to next para. Octal privileges are a codified way of representing file access privileges: read=4, write=2, execute=1. So read+write+execute is 7, read+execute is 5, read+write is 6, read only is 4, no permissions is 0. You can assign different privileges to the OWNER of the file or directory, those in the same GROUP as the file or directory, and to WORLD (everyone). That is three groups of three. A directory with all privileges available to owner, group and world is drwxrwxrwx, or 777. A file with read+write+execute privileges for the owner and read+execute privs for group and world is -rwxr-xr-x, or 755 (the first character is d for directory or – for a file). Ok, now we are clear on octal privileges.

    Now for WordPress uploads, lets assume your Linux user is “boris”, WordPress runs under the webserver user “apache” and you want to upload into wp-content/uploads.

    The wp-content/uploads directory needs privileges set to 770 (as does wp-content itself):
    drwxrwx— uploads boris apache 4096 May 19 07:17

    770 means boris has read(4)+write(2)+execute(1)=7 privs on the directory, apache has r+w+x privs on the directory, and world (public) has no privs on the directory.

    When you are using the image uploader (or any other time via a browser), WordPress is running under apache (the webserver). The directory is in the apache group, and the directory has group permissions of 7 – r+w+x.
    So WordPress – via apache – has write privileges to the directory it needs to upload

    755 won’t work. When you use 755, this is only r+x (4+1) for the group. No write privilege for apache, therefore no write privilege for WordPress and an error results.

    Execute permission on a directory means the contents of the directory can be listed. You can’t create a file in a directory without also having execute privileges (this protects you from creating a file that you can’t verify by listing), so the webserver user (apache) needs both write and execute privileges for WordPress to be able to upload.

    Technically files such as as jpg’s only need 660 permission (read + write). Execute permission is irrelevant for a file like a jpg (it doesn’t have an executable form).

    In summary, use 770 privileges for wp-content and wp-content/uploads if you want to be able to upload files via WordPress (and WordPress plugins, as they will also be running under the webserver). If you are connecting via ftp using your own user, you will have owner privs, usually r+w+x. World privileges are not required (or desirable). Using 770 for wp-content and uploads, you won’t need any special htaccess directives either.

    These principles apply all across WordPress directories e.g. themes updateable etc.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Advanced problem – image upload’ is closed to new replies.