[CentOS 5.8] 403 Error when accessing vhost directive (permission problems)

Ortix · 10-13-2012, 06:15 AM

Hey guys,

I'm having some troubles with setting up my webserver. It's a brand new server and I'm trying to set a vhost to the following dir:

/home/exo/public_html

However whenever I restart httpd I get the following warning:

Code:

Starting httpd: Warning: DocumentRoot [/home/exo/public_html] does not exist

Yes the directory does exist. So whenever I visit the domain exo-l.com it gives me a 403 error.

This is my config file (inside httpd.conf because the vhost conf is not being included, that issues will be discussed in another thread once i get this working since it has uber priority)

Code:

<VirtualHost *:80>
   DocumentRoot       /home/exo/public_html
   ServerName         www.exo-l.com
   ServerAlias        exo-l.com
   <Directory /home/exo/public_html>
        Order allow,deny
        Allow from all
   </Directory>
</VirtualHost>

I'm completely clueless because this should work as far as I know.

httpd is being run as apache:apache

i tried chowning the public_html directory (also recursively) to exo:apache, apache:apache, root:root with no success. chmod 777 doesn't do anything either.

a tail from the log:

Code:

[Sat Oct 13 15:09:47 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:09:47 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:09:48 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:03 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:04 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:04 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:04 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:04 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied
[Sat Oct 13 15:10:04 2012] [error] [client 82.***.***.61] (13)Permission denied: access to / denied

I also found something about selinux and that disabling it might help, but do I really want to do that?

bathory · 10-13-2012, 08:05 AM

Hi,

Make sure that you have the execute permissions set on that directory, so apache can descend into it

Code:

chmod 755 /home/exo/public_html

Regards

Ortix · 10-13-2012, 08:15 AM

that was the very first thing i checked.. and like i said in my post i tried 777 (which has read enabled as well)

In other words, that doesn't work

bathory · 10-13-2012, 08:37 AM

If it doesn't work, then it's SELinux. Use:

Code:

chcon -R -t httpd_sys_content_t /home/exo/public_html

and see if it helps

Ortix · 10-13-2012, 08:49 AM

Well goddamit that was it 0.o

just one simple trick and that did it!

What was exactly the problem? Why does this happen? Will this also work with phpmyadmin (that is also not accessible due to 403)

bathory · 10-13-2012, 09:14 AM

Glad to see it worked.
This happens if you change things (like the DocumentRoot) from their default values.
In centos the default docroot is /var/www/html and it's already labeled with the correct SELinux context. If you decide to use a different docroot, you need to label it accordingly.

Cheers

chrism01 · 10-16-2012, 12:26 AM

FYI, chcon does not survive a reboot; you need to add it to SELinux permanently

Code:

semanage -a -t httpd_sys_content_t /home/exo/public_html

mikey99 · 10-19-2012, 10:45 AM

Quote:

Originally Posted by chrism01

FYI, chcon does not survive a reboot; you need to add it to SELinux permanently

Code:

semanage -a -t httpd_sys_content_t /home/exo/public_html

Just to add a few comments.

Changing a label WILL survive a reboot, but it may not survive a full filesystem relabel.

However, there is aleady an entry for public_html in the targeted policy. Its not viewable when you do semanage fcontext -l , but it is in the policy. Try it. Create a directory called ~/public_html and run a restorecon -RF on the directory. It will change to httpd_user_content_t.

To be honest, it should automatically type transition to this context on creation. That is the job of the restorecond daemon via inotify. But it sometimes fails to do so, hence the manual running of the restorecon command.

Mike.

chrism01 · 10-22-2012, 12:04 AM

ah yes, sorry 'relabel' .... often happens at reboot