Directory index forbidden by rule
by Walt Stoneburner
"Son of a *&^%$!"
Lemme guess, you're facing the elusive
"DocumentRoot Directory index forbidden by rule" problem
with Apache. You've searched the web and found nothing of use.
I first bumped up against it running
Mambo, the OpenSource
dynamic portal engine and content management system; things
worked when the server was started manually as root,
but not if you rebooted the system and let /etc/rc.d
bring it up.
Your web page delivers this:
You don't have permission to access / on this server.
And your log says this:
Directory index forbidden by rule: some directory
Here's the solution.
Your problem has to do with the fact that Apache doesn't have permission
to access the directory your virtual site is trying to deliver.
"How can that be?" you wonder, knowing that your web server account
has full permission to the directory. And, quite possibly, you did
some clever testing and even got a file to serve, but it's still
not working right.
In the case of Options Indexes
the server is trying to read
the directory, because it's going to dynamically build you an index.
Problem it, it doesn't have permission to.
Yes, it has file
permissions, but not your
and blessing as the web master.
Go back and check your <Directory ...>
your virtual site's DocumentRoot
is listed there, Apache won't
be able to get at it.
listing in addition
to the DocumentRoot
. The reason it "normally" works is because
most of the time the directory is within Apache installation structure
or has been explictly provided by your distribution.
Note that /
may be denied, but /usr/local/apache/htdocs
is listed. You just need to add your own.
Example of correctly accessing a directory outside the tree:
Options All ExecCGI FollowSymLinks Includes Indexes
Allow from All
AllowOverride All Options
Options All ExecCGI FollowSymLinks Indexes
DirectoryIndex index.php index.html index.hml index.phtml index.shtml
You've put a file inside the Apache's html directory, and existing
files can be served, but new ones you created can't.
Even more confusing, if you copy or rename an existing file for
testing purposes, that works.
You've checked, and the file owners and permissions of the broken
files are identical to the working files. You've combed the
file and found nothing out of place.
What's wrong? You've been bit by SELinux.
The secure environment of SELinux, usually installed with Fedora Core 4,
provides a security context with each file, directory, device and so forth.
The easiest solution is to turn it off. Really.
Edit the file
/etc/selinux/config and set SELINUX=disabled.
You may need to reboot to make this change take affect.