13

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

1
  • 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, 2011 at 15:13

4 Answers 4

8

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

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

4
  • 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. Jul 25, 2011 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, 2011 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?
    – TMH
    Jul 21, 2014 at 23:05
  • @JakeWilson SELinux is rather frustrating when you're first getting accustomed to it. The more you learn how to use it, I promise you will appreciate it much more. Sep 20, 2016 at 21:26
16

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/document/root

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.

NOTE: The use of chcon conceptually has a downside per RedHat documentation (5.6.1. Temporary Changes: chcon) that states:

The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.

Use semanage and restorecon to make more permanent changes. A brief example:

 $ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
     "/path/to/document/root(/.*)?"
 $ sudo restorecon -FR /path/to/document/root

With regards to restorecon, note that -F is required to affect the whole context (i.e. user and type). Also, -R means to make changes recursively. Arguments -v or -p can show progress in either a verbose or terse fashion. Use -FRnv to see what would happen without actually making any changes.

Once semanage is used in this way, it is possible to view local security changes with a command like:

$ sudo semanage export

The output of semanage export may be saved and used by semanage import to make it easier to apply a set of changes to various systems.

NOTE: This answer provides a most basic type context for a site. Security can be much more granular. For example, see a list of types that can apply to web server pages with a command like:

$ seinfo -t | grep http

NOTE: Utilities like semanage and seinfo may not be installed by default. At least on some distributions, required packages may be named something like this:

policycoreutils-python
setools-console
1
  • Detailed, works and saves a lot of time - thank you! Aug 15, 2014 at 11:08
6

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
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .