1

I'm trying to change an apache web service's root web directory /var/www/html to my custom directory /mnt/webfiles. However, after configuring the /etc/httpd/conf/httpd.conf parameters and restarting httpd, my test directory/files still cannot be browsed from webpage.

Here's the environment:
OS: CentOS 7.9.2009
Apache version: 2.4.6
The installation type of OS: Basic web server

The purpose of using the apache web is just for test and there's no specific domain name requirement on this server, just IP address for client to browse web.

When I use the default directory /var/www/html to put test files, such as a simple .txt acting as simple webpage or a sub-directory download with a file in it to simulate download page, every thing works just fine. The webpage can be browsed via browser.

But, after changing DocumentRoot "/var/www/html" and Directory "/var/www"to my specific directory /mnt/webfiles, the test files/directories under /mnt/webfiles can never be accessed and the error message showed on browser would be like:

Forbidden
You don't have permission to access /download/ on this server.

Only the default apache webpage can be browsed and not affected.

What I did was following the instrucitons from this post and this one,

By the way, the permission of the files/directorues all the way from the root directory of apache web is root:root and 775, basically same as the /var/www/html.
I guess this is not the root cause.

Does anyone know why this happens?

0

1 Answer 1

2

One possible answer would be that SELinux is denying the new webroot.

Check if SELinux is enabled:

$ getenforce
Enforcing

Enforcing means that SELinux is enabled and enforcing the rules. A quick check to see if SElinux is really the problem would be to temporarily disable it:

$ setenforce 0

Reload the webpage and if it works now, SELinux is most likely the culprit.

But how to fix this permanently without having to disable SELinux?

Check the correct context of a webroot:

$ ll -Z /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 ..

Notice the httpd_sys_content_t tag!

This probably differs from your new webroot at /mnt/webfiles.

You need to define a correct context for the new webroot in the SELinux policy. Do this:

# This sets correct context in the policy
$ semanage fcontext -a -t httpd_sys_content_t "/mnt/webfiles(/.*)?" 

# This applies the context to the webroot
$ restorecon -v /mnt/webfiles

Then check if it worked. Remember to re-enable SELinux otherwise you won't be actually testing it :-)

$ setenforce 1

To check for denials, you can view the SELinux AVC denial log like so:

$ ausearch -ts recent -m avc

Also, if you need write access to the webroot, you may need to change the context from httpd_sys_content_t to httpd_sys_rw_content_t OR set the httpd_unified SELinux boolean to true:

$ setsebool -P httpd_unified 1
3
  • 1
    Spot on for using setenforce 0 only for diagnostics Sep 6 at 8:59
  • thank you so much. However, I found solution before seeing this post, which is chcon -R -t httpd_sys_content_t /mnt/webfiles, but I'm still trying to understand the meaning. Anyway, the issue just solved via using this commnad.
    – user53815
    Sep 7 at 8:25
  • 1
    @user53815 'chcon' indeed works, but is a temporary solution because it doesn't persist. Should the filesystem get relabeled for some reason, the SELinux policy will overwrite the contexts with the detault ones. If you run the semanage command I provided, that risk will be avoided. A good explanation can be found at access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…. Good luck!
    – Edward
    Sep 7 at 8:51

You must log in to answer this question.

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