David Lambros's picture

Hi all,

I'm having trouble uploading files to the Media library using either the browser upload or flash uploader. I receive this error:

“test.jpg” has failed to upload due to an error
The uploaded file could not be moved to /var/www/wordpress/wp-content/uploads/2013/05.

I've found that if I give 777 or 757 permissions to the "05" folder the upload works correctly. I'm new to linux and am having trouble diagnosing why this isn't working with the standard 755 permissions. My guess is that the "user account" wordpress is using is NOT the root account which seems to be the owner of the directory. 

Does this make sense? lol. Please help if you have a few minutes... 


Andrew Smith's picture

I don't think it's a "root" user issue. Directory permission should be "777" (read, write & execute) to upload the things.

David Lambros's picture

No kidding! Awesome. So if i recursively set permissions to 777 on the Upload folder will all newly created folders inherit the 777 permission? By default the wordpress media upload creates folders based on month and year and I don't want this problem to recur next month.

Jeremy Davis's picture

IMO it would be better to keep the permissions as 755 and give ownership to the webserver account (www-data). It probably doesn't make significant difference in the grand scheme of things but best practice is to keep permissions as tight as possible. Using 777 for testing is legitimate IMO, but there should be no need to leave permissions that loose in production. Root owned directories with 777 should have the same impact on WordPress as those dirs having 755 and owned by www-data. (FYI the 3 numbers refer to owner, group, others - 7 means read/write/execute; 5 means read/execute).

So personally I would do this:

chown -R www-data:www-data /var/www/wordpress/wp-content/uploads 
chmod -R 755 /var/www/wordpress/wp-content/uploads 
David Lambros's picture

Thanks Jeremy. After thinking about it I was getting uncomfortable with the 777 idea. Your post helps a ton. I'll try those commands right after I get a fresh backup. THANK YOU for your details explaination - it really helps a linux noob like me. :)

Jeremy Davis's picture

If you mean that you are on a Windows server, then sorry I have no idea. TBH I doubt anyone round here will... We are all Linux guys... :)

Jeremy Davis's picture

Then it should just work. However obviously something is not quite right. Also as you may already know, 777 permissions are a security risk...

Best thing to do is to give the webserver ownership of the location, like I said in my post above.

Jeremy Davis's picture

Follow the link that I posted above. This only applies to TurnKey Linux though. Having said that TurnKey is built on Debian (and Ubuntu is also built on Debian) so should also be relevant there. If you are using a different OS then I suggest that you post on their support forums (these are the TurnKey Linux forums).
Jeremy Davis's picture

But seeing as this is the TurnKey Linux forums (which is based on Debian) then www-data is the correct user/group (and would be for all Debian derivative OS).
Jeremy Davis's picture

Not that it should really matter, but in TKL you are root by default. If it is something which doesn't have root enabled (and you're using it) then sudo should work but perhaps it's setup wrong/locked down so sudo isn't getting full root type access? I don't know really, just throwing random ideas about...

I know you said you're confident the permissions are set ok but you can double check permissions with 'ls -la' (this will list all files/directories with ownership and permissions inc hidden ones). Also perhaps double check the WP config to make sure that it isn't trying to save/move stuff to somewhere that it doesn't have permission (i.e. outside of it's install directory).

Other than that, the only other thing that I could imagine trying is restarting Apache. TBH I have never heard of that causing a problem but I'm all out of ideas beyond that...

Jeremy Davis's picture

On Debian based systems (e.g. Debian, Ubuntu, Mint, etc) the Apache user is 'www-data'; AFAIK on RHEL based systems (e.g. RHEL, CentOS, Fedora, etc) the Apache user is 'httpd'.

Jeremy Davis's picture

chown -R www-data:www-data /var/www/wp-content
Jeremy Davis's picture

So here is a theoretical command:
chown -R user:group /some/directory

chown is the command to change ownership! :)

-R is the switch to use when you want to change ownership Recursively (i.e. /some/directory and all the sub-directories and files inside)

user is the username and group is the group name. By default on Debian all users are also automatically members of a group with the same name (as their username). So if I create a new user 'jeremy' it will automatically create a new user group also called 'jeremy' and the user 'jeremy will be a part of this new 'jeremy' group.

In Debian, the webserver runs under a special user account called 'www-data' (which as per above, also has a group by the same name).

/some/directory is a path. It can be to a file or a directory. However the use of the -R switch only makes sense if it's a directory!

So when I suggest:

chown -R www-data:www-data /var/www/yourwebsite/wp-content
What I am really saying is:
change ownership of /var/www/yourwebsite/wp-content so it and all it's contents belong to the webserver user and group

But your content path is different so the 'cut and paste' command won;t work!

By now I'm guessing you can probably work it out for yourself, but here it is anyway!:

chown -R www-data:www-data /opt/lampp/htdocs

Add new comment