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
Here's a tutorial approach to the SELinux case:
Find out if SELinux is active:
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:On the other hand, if SELinux contexts are applied,
ls -dZ
looks more like:If we compare to a working DocumentRoot, it would look something like:
The
_r
and_t
relate to-r
(--role
and-t
(--type
) arguments tochcon
. Here is a cut-down man page:At first guess, the following might seem to work, but might not.
If the web server still cannot see the DocumentRoot, note that the context matters all the way back to root:
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:
Use semanage and restorecon to make more permanent changes. A brief example:
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:
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:
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:
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
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.
So if that happens, I just apply the context from another directory, which in this case, is html:
Use this command in root to change the security context of “httpd_sys_content_t” which allows Apache to execute.
Use
ls -dZ /var/www/whatever
to view the details security roles