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

I'm having a problem setting up a vhost on Apache 2.4, using CentOS 6.3.

This question seems to have been answered several times on this forum, but none of the solutions work for me.

Basically, I set up a vhost with a particular document root. When I attempt to access the site, I get a permissions error. But I have no problem if I use a different root.

More specifically, if I set the root to be /volume1/web/xxx, I get a 503 because of a permission problem on index.html.

But if I set it to be /volume1/web, the index.html comes up without a problem.

The details:

  • I set the persmissions on volume1, web, and xxx to 755.
  • I set the permissions on the index.html files to 777.
  • I copy the index.html file to both /volume1/web and /volume1/web/xxx, so that they have identical index files with identical permissions.

In httpd.conf, I set the VirtualHost options so that I can easily switch the document root by changing 2 comment marks

I have the following lines in the conf file:

NameVirtualHost *:80

<VirtualHost *:80>
    ServerName localhost
    #DocumentRoot /volume1/web
    DocumentRoot /volume1/web/xxx

    #<Directory /volume1/web>
    <Directory /volume1/web/xxx>
      Options Indexes FollowSymLinks Includes ExecCGI
      AllowOverride All
      Order Allow,Deny
      Allow from all
    </Directory>

    ErrorLog logs/localhost-error_log
    CustomLog logs/localhost-access_log common
</VirtualHost>

These lines contain all the suggestions that worked for other people with the same problem.

What I get when I enter localhost in my browser depends on the document root.

  1. If the root is /volume1/web, the index.html page comes up.
  2. if the root is /volume1/web/xxx, then I get a 503 error, and the apache error log has this line:

    [Thu Jul 19 17:17:52 2012] [error] [client ::1] (13)Permission denied: access to /index.html denied

I also tried adding an index.php file to the directory. I then got permission denied messages for both the php file and the html file.

I also tried setting the user : group to apache : apache on the directories and files. That didn't help.

I've done everything I can think of to fix the permissions, to no avail.

Does anyone have an idea about what's happening here?

Thanks.

share|improve this question
add comment

3 Answers 3

up vote 6 down vote accepted

It appears you've created a new directory outside the standard filesystem hierarchy to hold your web documents.

When you do this, SELinux is not aware of your custom directory structure, and doesn't know that Apache (httpd) should have access to it. You will see messages in /var/log/audit/audit.log showing denials in this case.

To actually fix the problem, you need to tell SELinux that Apache can access the directory. Do this using the semanage fcontext command:

semanage fcontext -a -t httpd_sys_content_t "/volume1/web(/.*)?"

The pattern matching is done with regular expressions, so this will match /volume1/web and everything below it. The fact that it uses regular expressions also means you need to quote it as shown above.

Then relabel the files:

restorecon -r -v /volume1/web

SELinux will now permit Apache to access files in /volume1/web.

share|improve this answer
    
Thank you for the detailed response. It's inspired me to learn more about SELinux. –  oksofar Jul 24 '12 at 17:34
    
Red Hat's SELinux guide is very good; it's what I use. I linked to it in the answer. –  Michael Hampton Jul 24 '12 at 17:41
    
thanks. I have another question about this: I've not yet run semanage (it's not yet installed). But I CAN serve a page from /volume1/web, but not from /volume1/web/xxx. Do you have any idea why? Where can I find a list of what SELinux allows? –  oksofar Jul 24 '12 at 18:41
add comment

I'll point the finger of blame at SELinux. Verify by running setenforce 0 and re-trying.

share|improve this answer
    
Thank you, that worked. –  oksofar Jul 23 '12 at 18:55
    
Be careful. Turning off security features for troubleshooting is one thing, but you don't generally want to leave them turned off. –  Michael Hampton Jul 23 '12 at 23:41
    
@user129015 See Michael's comment and answer - turning off enforce is a troubleshooting step, not a solution. –  Shane Madden Jul 24 '12 at 0:19
add comment

- Desabilitar SELINUX e Reiniciar

SELINUX=disabled

SELINUXTYPE=targeted

#

grep ^SELINUX /etc/sysconfig/selinux

{ T=/tmp/OLD.selinux.$RANDOM$RANDOM$$ ;
  cp -f /etc/sysconfig/selinux $T ;
  sed -e 's@^SELINUX=.*@SELINUX=disabled@' \
      -e 's@^SELINUXTYPE=.*@SELINUXTYPE=targeted@' \
      < $T > /etc/sysconfig/selinux ;
} ;

xreboot ;

share|improve this answer
    
¿Que? Please use English in your posts. –  Deer Hunter Jul 1 '13 at 19:17
add comment

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.