apache + redmine 403 - premissions are good

问题

i searched sth about this a lot but solutions doesnt help so much.I tried to upgrade redmine to 2.6.5 on my FreeBSD but i have 403 error.

apache error log:

[autoindex:error] AH01276: Cannot serve directory /usr/local/www/redmine/public/: No matching DirectoryIndex (none) found, and server-generated directory index forbidden by Options directive

my httpd conf:

<VirtualHost example.com:80>
   DocumentRoot "/usr/local/www/redmine/public"
    ServerName example.com

      FastCgiServer /usr/local/www/redmine/public/dispatch.fcgi -idle-timeout 120 -initial-env RAILS_ENV=production -initial-env PATH=/usr/local/bin -processes 2

<Directory "/usr/local/www/redmine/public">
   AddHandler fastcgi-script fcgi
   Order allow,deny
   Allow from all
   AllowOverride all
   Options  +FollowSymLinks +ExecCGI
   RewriteEngine On
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.*)$ dispatch.fcgi
</Directory>
    ErrorLog /logs/error.log
</Virtualhost>

i have to say: if i add +Indexes in Option i see files in my browser, so i guess premissions are good. Anyone can give me any hint? thanks in advance 4 your help

回答1:

In my situation the problem was caused by a bug in the apache module ModAutoIndex. Disabling the module did the trick.

See https://serverfault.com/a/731859

Disabling the module auto index (which is the cause of the wrong behaviour, will prevent the error.

#LoadModule autoindex_module modules/mod_autoindex.so

Phusion will address the issue in the realase of Passenger 5.0.22 before Apache 2.5.0 will be released.

回答2:

I suffered the same issue on my ArchLinux installation with Apache 2.4 and Redmine 2.6.5. Instead of fcgi I use the Phusion Passenger web application server but I always ended up on a 403 Forbidden page like you when accessing the server.

With the +Indexes option I also got the contents of the Redmine public directory on the browser.

When using webrick or passenger directly to host Redmine everything was fine. That's how you can verify your Redmine is not corrupted somehow. From the Redmine root directory run:

bundle exec ruby scripts/rails server -e production 

Since I'm using RVM to manage ruby versions and gemsets on the system I can also tell you that the behavior is not related to ruby ( I tried every version from 1.8.x to 2.2.x without any change ).

In the end I substituted Apache with nginx 1.8.0 (stable release) and got Redmine back to work. So with passenger it's quite easy to get rolling. Just run

gem install passenger

so you get the passenger package. And then compile nginx with the passenger module using

passenger-install-nginx-module

You'll get an automated dialog that downloads nginx and compiles it with the appropriate config. By default it will be installed to /opt/nginx

On ArchLinux you would rather use the ABS to get the PKGBUILD and add the following to the configure part

--add-module=$(passenger-config --nginx-addon-dir) \

That way you also get the systemd unit-file to start and stop nginx.service

Last but not least here's the nginx config I use to run Redmine:

server {                                                                    
  listen 80;                                                              
  server_name redmine.example;                                        
  root /usr/share/webapps/redmine-2.6.5/public;                           
  passenger_base_uri /;                                                   
  passenger_app_root /usr/share/webapps/redmine-2.6.5;                    
  passenger_document_root /usr/share/webapps/redmine-2.6.5/public;        
  passenger_enabled on;                                                   

  passenger_ruby /usr/local/rvm/gems/ruby-1.9.3-p551@redmine/wrappers/ruby;
}

Using another webserver may be a daunting step but it took me less than 2 hours to get Redmine up and running with nginx compared to nearly 2 days of wasted time to figure out why the heck Apache didn't serve the webapp any more.

来源：https://stackoverflow.com/questions/33222480/apache-redmine-403-premissions-are-good