1

I installed Redmine on Fedora 18. The installation works when tested with webrick, as explained in the official HowTo.

Now I want to use Passenger and Apache to host Redmine. What I get is:

Passenger error #2 An error occurred while trying to access '/var/www/redmine/config/environment.rb': Cannot stat '/var/www/redmine/config/environment.rb': Permission denied (errno=13)

Apache doesn't have read permissions to that file. Please fix the relevant file permissions.

After several unsuccessful tries to resolve the problem, I gave the ownership of the whole /var/www/redmine directory including contents to the apache user and changed the permissions recursively to 777. I su'd to the apache user and could open and stat the environment.rb file without any problem. So I think that it is not a permission problem after all, but faced with this explicit error message, I am out of ideas.

What could be the problem here, and any ideas how to fix it (preferably a solution which allows me to change the permissions back to a sensible value)?

footnotes:

  • This is possibly related to this question.
  • I didn't forget to restart apache after changing the permissions.
  • I am running httpd version 2.4.4-2.fc18, Phusion Passenger version 4.0.4 Redmine version 2.3.1.
3
  • Take a look here. This is probably related to SELinux, what AVC denials have you logged so far?
    – dawud
    May 28, 2013 at 19:35
  • @dawud thank you, I had not thought that Fedora may have SELinux enabled by default. As for the link, maybe I was not clear enough - I did not set full permissions to the whole system, just to a subfolder of /var/www, on a system which is not yet in production use. If you want to add an answer, I will accept yours.
    – rumtscho
    May 28, 2013 at 19:59
  • Check my comment on your answer. Try the solution i proposed there, and if you can make it work, edit your own answer.
    – dawud
    May 28, 2013 at 20:11

1 Answer 1

1

I had forgotten that Fedora has SELinux enabled by default. Turning off SELinux removed the error.

As pointed out by dawud, turning off SELinux should not be considered a solution - rather, SELinux should be configured to permit Apache to use the files.

The quick solution was to run restorecon on the directory in question. This sets the security context to the type expected of the parent directory. My files being in a subdirectory of /var/www, they were set to httpd_sys_content_t, and Apache was allowed to access them. If they had been somewhere else, I would have had to change the type manually.

After solving the SELinux issue, the file permissions can be chmoded back to the usual level without further problems.

3
  • 2
    Don't disable SELinux, please. If you are not versed enough in it so as to set it up properly, at least set a permissive domain for Apache instead of disabling it.
    – dawud
    May 28, 2013 at 20:10
  • @dawud While security is not a problem in my very limited case (this is a personal project and the machine is only accessible from the local network), good point about getting a robust solution for the general case. At least it was a good diagnosis for the root cause.
    – rumtscho
    May 28, 2013 at 20:21
  • @dawud answer expanded to include the proper solution.
    – rumtscho
    May 30, 2013 at 14:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .