我们正在升级到Fedora 18.我们已经部署了我们的Rails应用程序， 除了下载报告的zip文件之外 ，它的工作方式和预期一样。 它适用于我们现有的生产服务器（Fedora 15）。
我们使用XSendFile发送zip文件。 当文件位于/tmp时不起作用，但在其他情况下可以使用。
这些zip文件是使用Ruby中的Tempfile.open生成的，默认情况下它会在/tmp创build一个文件。 但是，Apache给了我们一个404错误，在error_log这样的错误：
[Thu May 02 11:33:18.010388 2013] [:error] [pid ...] (2)No such file or directory: [client ...] xsendfile: cannot open file: /tmp/..., referer: https://...
我们首先检查的是我们的configuration。 这就是我们所拥有的：
XSendFile on XSendFilePath /tmp
这似乎是正确的， 因为文档 – 甚至在示例中使用/tmp 。
我们开始试图缩小这个问题的范围。 我们开始强制Rails应用程序通过硬编码path来服务其他文件。 每一次，我们XSendFilePath改变Apacheconfiguration中的XSendFilePath目录和Rails应用程序中使用的文件path。
结果：
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
在失败的情况下，权限设置为777 apache：apache，这看起来足够自由。 虽然，工作案例不需要这些权限。
因为我们怀疑/tmppath是问题，所以我们使/tmp2具有相同的权限和所有权（ drwxrwxrwt.和root:root ）。 /tmp2的SELinux上下文使用chcon更改为相同。
即使有这些变化， XSendFile 可以和/tmp2 。 这使得这个问题似乎是一个Apacheconfiguration问题。 我们可以解决这个问题，但是我们不想这样做。
我们缺less什么让/tmp2工作，但不是/tmp ？
mod_xsendfile 0.12（来自Fedora 18的RPM，不是我们编译的东西） 注：我们正在使用mod_security ，但它不是在执行模式。