Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I used Webmin to create the following Virtual Host:

<VirtualHost *:80>
        DocumentRoot "/var/www/whatever"
        ServerName whatever.ourdomain
        <Directory "/var/www/whatever">
                allow from all
                Options +Indexes
        </Directory>
</VirtualHost>

And when restarting Apache I get

Starting httpd: Warning: DocumentRoot [/var/www/whatever] does not exist

The thing is, the directory absolutely DOES exist. I'm staring right at it. pwd shows me that's my current directory, etc. It's not that hard to spell it right. I can't find any other errors or warnings in the httpd logs. apache:apache owns the directory and all subdirectories/files. There isn't any symlinks or anything involved here. What am I missing or what else should I look at to determine why this is?

OS is CentOS 6.0

share|improve this question
    
su to the Apache user and see if it can access the DocumentRoot, that might give you some insight into what the web server is seeing. You may also want to check the other directories along the path, though if it's really under /var/www/ those should not be a problem –  voretaq7 Jul 25 '11 at 15:13

4 Answers 4

up vote 6 down vote accepted

The first thing that popped into my mind is does Apache have permission to access that directory?

Also, this: http://stackoverflow.com/questions/3948038/apache-says-my-documentroot-directory-doesnt-exist

share|improve this answer
1  
As I said, yes the directory is owned by apache:apache, however I followed that link (that is on SO for some reason?) and indeed SELinux was the problem. SELinux causes more problems that it does good imo. –  Jakobud Jul 25 '11 at 15:11
    
selinux is annoying at first, but if you know the commands to manage access, it is actually not as daunting. It's a good tool to use once you get used to it. –  Rilindo Jul 25 '11 at 17:41
    
I had the same issue (Doesn't exist on a symlink), and running setenforce 0 fixed it, but looking at the permissions ls-laZ, the symlink has the same permissions as other files it can access, apart from chmod. The files are -rw-r--r--, and the symlink is lrwxrwxrwx. Could that be the reason it doesn't work with setenforce 1? –  Tom Hart Jul 21 at 23:05

Here's a tutorial approach to the SELinux case:

Find out if SELinux is active:

 $ sestatus
 SELinux status:                 enabled
 SELinuxfs mount:                /selinux
 Current mode:                   enforcing
 Mode from config file:          enforcing
 Policy version:                 24
 Policy from config file:        targeted

If so, some comparative checking might help. For instance, a server has a default DocumentRoot at /var/www/html, but we want it somewhere else like /path/to/document/root.

If SELinux is not actively messing with the resource, ls -dZ on the directory will show something like:

$ ls -dZ /path/to/document/root
? /path/to/document/root/

On the other hand, if SELinux contexts are applied, ls -dZ looks more like:

$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/documentroot

If we compare to a working DocumentRoot, it would look something like:

$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

The _r and _t relate to -r (--role and -t (--type) arguments to chcon. Here is a cut-down man page:

NAME
   chcon - change file security context

SYNOPSIS
   chcon [OPTION]... CONTEXT FILE...
   chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
   chcon [OPTION]... --reference=RFILE FILE...

DESCRIPTION
   Change the security context of each FILE to CONTEXT.  With --reference,
   change the security context of each FILE to that of RFILE.

   --reference=RFILE
          use RFILE's security context rather than  specifying a CONTEXT value

   -R, --recursive
          operate on files and directories recursively

At first guess, the following might seem to work, but might not.

$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root

If the web server still cannot see the DocumentRoot, note that the context matters all the way back to root:

$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path

At this point, the web server can see the directory.

Yes, I learned the hard way tonight.

share|improve this answer
    
Thanks for the great explanation, sir! –  lorenzo.marcon May 25 at 13:22
    
Detailed, works and saves a lot of time - thank you! –  NorthBridge Aug 15 at 11:08

It sounds like SELinux.I would suggest you work with it. Look in the /var/log/audit directory to confirm.

Worse case, you can always turn off selinux, as noted earlier, but I suggest you work with it instead. For instance, if I were to create a directory for use with Apache, it will not have the right context, as noted here.

[root@amp23140 www]# ls -Z
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 whatever

So if that happens, I just apply the context from another directory, which in this case, is html:

[root@amp23140 www]# chcon whatever --reference=html
[root@amp23140 www]# ls -lZ
drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 cgi-bin
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 error
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 icons
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 whatever
share|improve this answer

Use this command in root to change the security context of “httpd_sys_content_t” which allows Apache to execute.

chcon -R -h -t httpd_sys_content_t /var/www/whatever

Use ls -dZ /var/www/whatever to view the details security roles

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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