Red Hat Bugzilla – Bug 250910
Httpd Not Mapping to User Directories
Last modified: 2015-03-04 20:18:58 EST
Description of problem:
The httpd daemon is not translating the user directory URL to the correct
directory as defined in the httpd.conf file. Instead it is interpreting the
tilde (~) as a literal character and mapping back to the WWW root directory.
i.e. Using URL http://www.my-domain.com/~user, httpd resolves this as
This has been tested with both SElinux on and off with the same result. The
resulting error in the httpd error.log file is:
[Sun Aug 05 11:19:51 2007] [error] [client XXX.XXX.XXX.XXX] File does not
Verifying that the SELinux settings are correct and the directory permissions
Directory permissions =
a) drwxr-xr-x 6 root root 4096 2007-06-02 16:26 /home
b) drwx--x--x 42 user user 4096 2007-06-04 19:46 /home/user/
c) drwxr-xr-x 2 user user 4096 2007-06-04 19:46 /home/user/public_html/
The SElinux types are =
user_u:object_r:httpd_sys_content_t for the directory /home/user/public_html/
Checking that user directories is enabled in SElinux =
[root@undine ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on
Checking that the user_dir module is loaded in apache using phpinfo() script
produces the following results:
core prefork http_core mod_so mod_auth_basic mod_auth_digest mod_authn_file
mod_authn_alias mod_authn_anon mod_authn_dbm mod_authn_default mod_authz_host
mod_authz_user mod_authz_owner mod_authz_groupfile mod_authz_dbm
mod_authz_default util_ldap mod_authnz_ldap mod_include mod_log_config mod_logio
mod_env mod_ext_filter mod_mime_magic mod_expires mod_deflate mod_headers
mod_usertrack mod_setenvif mod_mime mod_dav mod_status mod_autoindex mod_info
mod_dav_fs mod_vhost_alias mod_negotiation mod_dir mod_actions mod_speling
mod_userdir mod_alias mod_rewrite mod_proxy mod_proxy_balancer mod_proxy_ftp
mod_proxy_http mod_proxy_connect mod_cache mod_suexec mod_disk_cache
mod_file_cache mod_mem_cache mod_cgi mod_auth_mysql mod_security2 mod_unique_id
mod_perl mod_php5 mod_proxy_ajp mod_python mod_ssl
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. httpd.conf file with the following entry =
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Allow from all
<LimitExcept GET POST OPTIONS>
Deny from all
2. Disk set up as follows (or similar) =
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /home type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
NOTE: The /home directory is on a separate partition from the main volume
despite the logical volume spanning /dev/sda and /dev/sdb.
3. Create a user and have a public_html directory created in their home
directory. Set the appropriate permissions to allow world read and execute
4. Change SElinux policy for HTTPD to allow user home directories.
5. Create simple index.html file in the user public_html directory.
6. Open browser and try to navigate to user directory.
Receive "404 Not Found" error and httpd tries to resolve the URL to the Document
Root directory with ~user
Httpd to resolve the http://www.my-domain.com/~user request to the correct
directory on the server. (e.g. /home/user/public_html)
Created attachment 160707 [details]
httpd.conf file used to configure server
What SELinux warnings do you get (audit.log)?
I receive no SELinux warnings in the audit.log. Nothing shows in the
setroubleshootd.log file either. The only entries found are the following httpd
XXX.XXX.XXX.XXX - - [11/Aug/2007:09:11:42 +1000] "GET /~user HTTP/1.1" 404 335
"-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20070718
[Sat Aug 11 09:11:42 2007] [error] [client XXX.XXX.XXX.XXX] File does not exist:
[11/Aug/2007:09:21:04 +1000] oPzHWX8AAAEAAALLF1cAAAAD XXX.XXX.XXX.XXX 45624
GET /~user HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20070718
HTTP/1.1 404 Not Found
Keep-Alive: timeout=15, max=100
Content-Type: text/html; charset=iso-8859-1
Apache-Error: [file "/builddir/build/BUILD/httpd-2.2.4/server/core.c"] [line
3633] [level 3] File does not exist: /var/www/html/~user
Stopwatch: 1186788064151385 3531 (481 3046 -)
Producer: ModSecurity v2.1.1 (Apache 2.x)
Server: Apache/2.2.4 (Fedora)
Found out what the problem is. In the directory /etc/httpd/conf.d, there was a
file system-config-httpd.conf which had the UserDir directive set to "disable".
This setting was overriding the values set in the httpd.conf file in
After changing the UserDir directive to public_html in the
system-config-httpd.conf, apache is now doing what it should be.
Maybe if this setting is either removed from the system-config-httpd.conf or the
system-config-httpd applet allows the user to toggle/configure this setting in
there this issue could be addressed.
I agree, it seems like a recipe for confusion.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Ran into this exact problem as well on a fresh install of Fedora 9. Initially
ran system-config-httpd to try to configure the httpd server. However, there was
no option to enable the UserDir feature with system-config-httpd, so I did what
I thought was the obvious thing to do, and edited httpd.conf to try to enable
UserDir. After beating my head against the wall for a long period, I found this
helpful bug entry, and realized that system-config-httpd.conf was the problem.
I would suggest that the UserDir configuration needs to go in one of these .conf
files, not both. As it is right now, the feature needs to be enabled in both
files for UserDir to work.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.