Here's a tutorial approach to the SELinux case:
Find out if SELinux is active:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
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:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
On the other hand, if SELinux contexts are applied, ls
-dZ looks more like:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/documentroot
If we compare to a working DocumentRoot, it would look something like:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
The _r and _t relate
to -r (--role and -t (--type)
arguments to chcon.
Here is a cut-down man page:
NAME
chcon - change file security context
SYNOPSIS
chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
DESCRIPTION
Change the security context of each FILE to CONTEXT. With --reference,
change the security context of each FILE to that of RFILE.
--reference=RFILE
use RFILE's security context rather than specifying a CONTEXT value
-R, --recursive
operate on files and directories recursively
At first guess, the following might seem to work, but might not.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
If the web server still cannot see the DocumentRoot, note that the context matters all the way back to root:
$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path
At this point, the web server can see the directory.