1

This is driving me insane. httpd runs as the user apache. I have two directories within /var/www/html -- uploads and photos. Both have group:owner of apache:apache. Both are 755. uploads is writable from php -- photos is not.

Some test code:

var_dump(touch('/var/www/html/photos/_test.log'));
var_dump(touch('/var/www/html/uploads/_test.log'));
var_dump(touch('/var/www/html/uploadsasdf/_test.log'));

And results:

Warning: touch(): Unable to create file /var/www/html/photos/_test.log because Permission denied in /var/www/html/test.php on line 2
bool(false) 
bool(true) 
Warning: touch(): Unable to create file /var/www/html/uploadsasdf/_test.log because Permission denied in /var/www/html/test.php on line 4
bool(false)

I've confirmed permissions through a shell and GUI interface. I've chowned and chmoded everything again just to be sure. I've renamed the uploads directory to something else and renamed photos to uploads to see if the name of the directory was the key here, but it wasn't. It's the directory itself. The renamed uploads still works with a new name, and the photos directory that is now called "uploads" does not.

Of note, _test.log does not exist in the folders before testing, so it's not like that file has bad permissions or anything.

Interestingly, if I create a new directory, chown it to apache:apache, chmod it to 777, I can't write to it, so something larger may be wrong here; but the question remains: why then does the uploads directory work?

Has anyone seen this behavior before? Am I missing something obvious?

Thanks in advance for any help!

Edited to add more info:

exec('whoami')

"apache"

var_dump(posix_getpwuid(fileowner('/var/www/html/')));
var_dump(posix_getpwuid(fileowner('/var/www/html/uploads/')));
var_dump(posix_getpwuid(fileowner('/var/www/html/photos/')));

all "apache"

All have the same fileperms() value. However, is_writable() is false on all but "uploads".

mkdir('var/www/html/test');

Warning: mkdir(): Permission denied

ls-alF

drwxr-xr-x.  2 apache apache 286720 Nov 22 15:17 photos/
drwxr-xr-x.  2 apache apache  81920 Nov 22 12:06 uploads/
drwxr-xr-x.  2 apache apache      6 Nov 22 10:31 uploadsasdf/

I have called clearstatcache(); I have rebooted the server. What ... on ... Earth?

Sarthaz
  • 126
  • 9

2 Answers2

4

Since you are using CentOS and and you've tried everything else, my guess would be something related to SELinux. One of the answers from this question may be helpful Forbidden You don't have permission to access on this server. Centos 6 / Laravel 4

Specifically try this to analyze SELinux permissions (ls -lZ) and temporarily disable SELinux:

If you're using CentOS it could be an issue with selinux. Check to see if selinux is enabled with 'sestatus'. If it is enabled, you can check to see if that is the issue (temporarily) using 'sudo setenforce 0'. If apache can serve the site, then you just need to change the context of the files recursively using 'sudo chcon -R -t httpd_sys_content_t' (you can check the existing context using 'ls -Z'.

Community
  • 1
  • 1
phansen
  • 411
  • 3
  • 7
  • Thank you! I'm marking this as the answer, since it was first and led me down the correct path. The issue was indeed selinux related, but chcon would not work for some reason, and semanage was not installed on this server. So I yum installed semanage, and then ran the following two commands to add a new context and then apply it: **semanage fcontext -a -t httpd_sys_rw_content_t /var/www/html/photos** ... **restorecon -Rv /var/www/html/** – Sarthaz Nov 24 '14 at 14:19
1

If selinux is enabled (sestatus will tell you), try sudo restorecon -Rv /var/www/ first. Sounds much like SELinux is getting in the way and you somehow have got a file/directory there which is not labelled correctly. Restorecon will revert labels to default, and -v will show you which labels have been corrected, if any.

Failing that, extended attributes come to mind. do lsattr <filename> and if the output looks anything like ------i-----, the immutable flag is set. Change it with chattr -i <filename> and you're good to go.

sysconfig
  • 1,369
  • 10
  • 15
  • Thank you for the help! restorecon by itself did not work, but this answer helped lead me to a solution. photos and uploads were created at the same time by the same process, so I don't understand why one needs a special context rule and the other doesn't, but it's working now. – Sarthaz Nov 24 '14 at 14:31
  • 1
    @Sarthaz Glad you fixed it. Why the context labels got messed up is difficult to diagnose without some serious digging. (A common cause is moving files around, possibly with SELinux temporarily disabled at the same time.) I'll give you an upvote for actually fixing the cause and sharing it here, not just switching off SELinux, which most people out there would *sadly* recommend! :) – sysconfig Nov 24 '14 at 14:56