We're upgrading to Fedora 18. We've deployed our Rails app, and it works as expected, except for downloading zip files of reports. It works on our existing production server (Fedora 15).
XSendFile to send the zip files. It doesn't work when the files are located in
/tmp, but it works in other circumstances.
The zip files are generated using
Tempfile.open in Ruby, which creates a file in
/tmp by default. However, Apache gives us a 404 and an error like this in
[Thu May 02 11:33:18.010388 2013] [:error] [pid ...] (2)No such file or directory: [client ...] xsendfile: cannot open file: /tmp/..., referer: https://...
The first thing we checked is our configuration. This is what we have:
XSendFile on XSendFilePath /tmp
That seems to be correct given the docs --
/tmp is even used in the example.
We started trying to narrow down the problem. We started forcing the Rails app to serve other files by hardcoding the path. Each time, we'd change the directory for
XSendFilePath in the Apache config and the file path used in the Rails app.
fails: /tmp/hello.zip works: /var/www/html/rails_production/current/public/hello.zip works: /home/capistrano/hello2.zip fails: /tmp/test-xsendfile/hello3.zip works: /tmp2/hello4.zip
In the failing cases, the permissions were set to 777 apache:apache, which would seem liberal enough. The working cases didn't require those permissions, though.
Because we are suspecting the
/tmp path to be the issue, we made
/tmp2 with the same permissions and ownership (
root:root). The SELinux context for
/tmp2 was changed to be identical using
Even with those changes,
XSendFile works with
/tmp2. That makes the problem seem to be an Apache config issue. We can work around this, but we'd prefer not to.
What are we missing that lets
/tmp2 work, but not
- Apache 2.4.4
mod_xsendfile0.12 (RPM from Fedora 18, not something we compiled)
NOTE: We're using
mod_security, but it isn't in enforcing mode.