Apache restart causes DocumentRoot must be a directory, even though it is a directory and there seem to be no privilege issues

Question

I have what is almost certainly a newbie question. I expected to find the issue while writing this question, but I am still stuck.

I want to change the DocumentRoot for apache, but I keep getting the error message "DocumentRoot must be a directory".

Situation:

• The code is running in a virtual VMWare machine 4.0.4 build-744019
• The version of linux is Scientific Linux release 6.4 (Carbon)
• The version of apache is Apache/2.2.15 (Unix) (this is a yum install with nothing special)

In the httpd.conf

DocumentRoot "/home/stave/www" 

When I restart, I get the message

Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf: DocumentRoot must be a directory 

Steps taken so far:

I ensured that the directory exists:

ls -asl /home/stave 4 drwxrwxrwx.  2 stave stave    4096 Feb  9 09:08 www It even has a file in it "index.html", so I am very sure that the directory exists 

I considered that it might be a priviledges issue so (this is a virtual development machine isolated from the internet, and I am troubleshooting so I am not too worried about security) as you can see I set the priviledges to 777.

I even changed the user that apache is running as (and confirmed that the change worked with ps) to stave to ensure that priviledges just shouldn't be an issue.

Stackoverflow

There are a few stack overflow answers, but most of them say "read the error message. It is saying that the directory doesn't actually exist". Others implied that there might a trailing slash at the end which would be bad.

Other websites

The most useful I found was this that advised

You probably got "DocumentRoot must be a directory" error even it is really a directory because of SELinux extensions. Run system-config-securitylevel (or redhat-config-securitylevel) to disable SELinux for httpd or give SELinux permissions to that directory: chcon -R -h -t httpd_sys_content_t /path/to/directory*

My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.

Current situation

I have run out of ideas to try, so any diagnostic questions or advice would be greatly appreciated

Answer 1

The link you posted under "Other websites" highlights the root cause of your problem, which is Selinux.

Unless the server is part of a super secure environment, I would simply disable Selinux.

On RedHat / CentOS / Scientific Linux this can easily be done by editing /etc/sysconfig/selinux - find the parameter "selinux" and change the option "enforcing" to "disabled" as per the extract below:

# SELINUX= can take one of these three values: #       enforcing - SELinux security policy is enforced. #       permissive - SELinux prints warnings instead of enforcing. #       disabled - No SELinux policy is loaded. SELINUX=disabled 

It is probably wise to reboot the server after making this change.