1

Using Apache 2.4.10 on two different Linux hosts. The server configurations are very similar, and running very similar php web applications.

With one server, the uri /uploads produces:

Access forbidden!

You don't have permission to access the requested directory. There is either no index document or the directory is read-protected.

If you think this is a server error, please contact the webmaster.

With the other server, that uri produces a listing of the files in the uploads directory below the document root.

On both servers I've done

grep -i Indexes

in all of the .conf and .htaccess files on both servers, and all I find is:

Options FollowSymLinks Indexes

There is no index.html file in that directory, though it is readable to the httpd process. What else could cause this difference? Is there a way to verify what Options settings are in effect for httpd, or show what changes them? Or other ideas for figuring out what's going on?

Improve this question
12
  • Does this question on StackOverflow answer your question? Error message “Forbidden You don't have permission to access / on this server” It talks about directory indexes, deny allow directives, require directives, and file permissions.
    – Stephen Ostermiller ♦
    Commented Jan 27, 2017 at 18:45
  • Check the owner, group, and permissions of your folder. Keep in mind that Apache has to be able to read the directory. Depending upon the install, that can be one of several user names. However, root access is often required even if Apache is sand-boxed. Also, check the conf files or .htaccess file to ensure that options indexes is enabled. It is also possible that the files are uploaded using another user name and permissions that Apache has no access to. Cheers!!
    – closetnoc
    Commented Jan 27, 2017 at 19:00
  • What happens when you request /uploads/ (ie. with a trailing slash)? If you do (temporarily) put an index.html file in that directory (assuming that is a defined DirectoryIndex), is it served? Have you tried it with another "test" directory?
    – MrWhite
    Commented Jan 27, 2017 at 19:50
  • Thanks for helpful comments, but @Stephen Ostermiller: the reference is about access to "/" - if that were the problem, I couldn't see anything. I can access files within the uploads directory, but giving the url for the directory itself gives a listing on one server, and access denied on the other.
    – sootsnoot
    Commented Jan 28, 2017 at 19:58
  • @closetnoc I did check those things, and in fact I can access files within the directory, which is 775. And as I said in the original post, I ran "grep -i Indexes" on all of the conf files and .htaccess. I also grepped for Options.
    – sootsnoot
    Commented Jan 28, 2017 at 20:00

1 Answer 1

Reset to default
1

In poring over the config files again, I see that both servers have identical httpd.conf files, but they include different files from the "extra" subdirectory to define the vhosts. (I'm based on XAMPP for Linux 1.8.2-6, which has httpd.conf in /opt/lampp/etc/ and a directory /opt/lampp/etc/extra/ containing various other conf files, including vhosts.conf).

The common httpd.conf file has DocumentRoot "/opt/lampp/htdocs" and it contains roughly this near the top:

<Directory /> AllowOverride none Require all denied </Directory> <Directory "/opt/lampp/htdocs"> Options Indexes FollowSymLinks ExecCGI Includes AllowOverride All Require all granted </Directory>

On the server that gives a directory listing, the vhosts.conf file contains no Options directives at all. So it makes perfect sense that the Options directive from httpd.conf effectively enables Indexes.

On the server that gives the Access Denied error, the vhosts.conf file contains these directives:

<Directory /opt/lampp/htdocs> AllowOverride None Options FollowSymLinks </Directory> <Directory "/opt/lampp/htdocs/xampp"> AllowOverride All Options FollowSymLinks Indexes </Directory> <Directory "/opt/lampp/htdocs/test"> AllowOverride All Options FollowSymLinks Indexes </Directory> <Directory "/opt/lampp/phpmyadmin"> AllowOverride All Options FollowSymLinks Indexes </Directory>

I think what's happening is that because none of the Options directives contain "+" or "-" prefixes on their attributes, the Options FollowSymLinks directive in the first directory section of this file has the effect of cancelling all the other attributes (including Indexes) from the first Options directive in the httpd.conf file!

And in fact I just "proved" it by editing the vhosts.conf file on the server that gave the directory listing, to add:

<Directory /opt/lampp/htdocs>
    Options       FollowSymLinks
</Directory>

That one change (and running lampp reloadapache) caused that server also to give the access denied error, just like the other server.

Although I could leave things this way, I think I'll change all three configuration files to start out with Options None for "/" and Options +FollowSymLinks +Indexes +ExecCGI +Includes for "/opt/lampp/htdocs" in the httpd.conf file. And in the vhosts.conf files I'll put:

<Directory /opt/lampp/htdocs> Options +FollowSymLinks -Indexes -ExecCGI -Includes </Directory>

Improve this answer
6
  • Where is the /uploads dir located? Providing it is a physical subdir of either .../xampp or .../test then Indexes should be enabled, since Options FollowSymLinks Indexes (defined in the more specific <Directory> container) should completely override Options FollowSymLinks (defined in the parent) - it shouldn't have anything to do with + or - prefixes in this instance. (Note that you do appear to need FollowSymLinks as well in order to enable directory indexes.) So, unless /uploads is located elsewhere, I think the jury is still out on what is really going on here. (?)
    – MrWhite
    Commented Jan 29, 2017 at 11:38
  • 1
    @w3dk: It's /opt/lampp/htdocs/WWW/public/uploads/, where the virtual host in question has DocumentRoot /opt/lampp/htdocs/WWW/public. The first Options directive, in httpd.conf, is for /opt/lampp/htdocs, so it's not a more specific container, but the same container. I didn't expect the second directive to remove the options that were specified on the first directive for that container that were not repeated on the second one, but I guess that's what "not merged" means in the documentation. So I think the case is closed. Sorry that I didn't give the full directory tree.
    – sootsnoot
    Commented Jan 29, 2017 at 16:58
  • Yes, in that case, a request for your /uploads directory is only matched by the first <Directory /opt/lampp/htdocs> container, which resets the Options to FollowSymLinks only (essentially removing Indexes, ExecCGI, and Includes set earlier in the server config) thus removing the directory index capability. The AllowOverride None directive would also prevent any .htaccess file from re-enabling it.
    – MrWhite
    Commented Jan 29, 2017 at 19:42
  • Okay, thanks, I'm marking this the accepted answer. And once again I apologize for not laying out the directory structure completely. I had sort of assumed that saying I was based on XAMPP implied that the document root of each virtual host was /opt/lampp/htdocs/virthost/public, so that the uri /uploads would be below that - but I now realize that's not necessarily the case at all, it is just a convention I've always used since building a Zend Framework MVC application. Thanks for your patience.
    – sootsnoot
    Commented Jan 30, 2017 at 4:35
  • Actually, the thing that threw us initially was that you stated: "...all I find is: Options FollowSymLinks Indexes" - if that was the case then Indexes should have been enabled regardless of your directory structure. Yes, you can't assume anything about the directory structure. In fact, /opt/lampp/htdocs/virthost/public is arguably not the recommended location for your virtual hosts since you are essentially creating websites within the parent (XAMPP example) website and inheriting the config associated with that which must now be explicitly overridden - unless the sites are related.
    – MrWhite
    Commented Jan 30, 2017 at 10:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.