I am attempting to upload images through my web application onto the server. I have found that 771 permissions on the parent directory is acceptable on my local machine. However, on the web server, even 777 directories do not allow me to upload pictures.

Assuming the code itself is not flawed, what could be going on here? The one difference I note, even tracing all the way up through the directory hierarchy, is that the files are owned by (and part of group) 'daniel' on my local machine, whereas 'root' owns them on the web server. Otherwise I see no differences.

I can fill in any other details if required.

migrated from stackoverflow.com Sep 7 '11 at 7:34

This question came from our site for professional and enthusiast programmers.

  • do you have control of the webserver or is it shared hosting? My guess is that the webserver is running under suphp or something similar. You need write/execute permission to the directory. This can be for either the user or group that the web server process is running as, or for all (insecure). But without more information about the webserver is running, it will be hard to debug. – Doon Sep 7 '11 at 3:10
  • I do have control over the webserver. I'm running apache. As mentioned, the relevant directory has full permissions (for testing purposes), but this is still not enough. As mentioned above, 771 permissions worked just fine on my local machine. – Paragon Sep 7 '11 at 4:02
  • just do a phpinfo(); on the page, it will show the effective UID/GID. but if you have a 777 directory and it isn't working it could be something else. What error message do you get when you try to upload? is file_uploads = On in your php.ini file. What does the web server error log show? – Doon Sep 7 '11 at 4:16
  • file_uploads is on. The error message is: "Server error. Upload directory isn't writable." – Paragon Sep 7 '11 at 4:23

These find commands should do the trick:

  1. Assuming your apache is running as the www-data user. It could be nobody as well. This will fix the ownership:

    find /path/to/your/docroot ! -user www-data -exec chown www-data:www-data {} \;

  2. Fix perms on directories:

    find /path/to/your/docroot -type d ! -perm 755 -exec chmod 755 {} \;

  3. Fix perms on files

    find /path/to/your/docroot -type f ! -perm 644 -exec chmod 644 {} \;


Apache or httpd has to be UID or GID also. And have read, write and execution permissions.

  • Hmm, okay. I'll have to research UID's and GID's tomorrow when I'm not so sleepy, as I do not know what they are. I am indeed using apache, although I do not know what permissions the web server itself has. – Paragon Sep 7 '11 at 4:04
  • Apache‘s service is called httpd in most GNU/Linux distributions. To get either UID or GID as httpd (assuming that httpd is the group and user name) use chown -Rfv :httpd to recursively set a directory GID to httpd, or chown -Rfv httpd to set its UID. – user93997 Sep 7 '11 at 14:56
  • I attempted to do as you asked, but it says that both 'httpd' and ':httpd' are invalid users. I also tried 'apache' and ':apache' to the same result. – Paragon Sep 7 '11 at 22:50
  • Then you will have to check the actual username for the server. Try with a ls -ls in your served directories to check who owns the files. – user93997 Sep 8 '11 at 3:11
  • Currently, root owns the files (whereas 'daniel' owns the files on my local machine). I'm trying to figure out the username of the server, but it seems to be non-trivial. Any tips would be helpful! – Paragon Sep 9 '11 at 4:09

on ubuntu, apache runs with the www-data user/group

so if you chown -R www-data pic/dir or chgrp -R www-data pic/dir it should work.

if you chgrp make sure to use at least 775 on the directory, whereas the chown you can use 755 permissions on the directory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.