Rails：SQLite3::CantOpenException：无法打开数据库文件答案

【问题标题】：Rails: SQLite3::CantOpenException: unable to open database fileRails：SQLite3::CantOpenException：无法打开数据库文件
【发布时间】：2012-09-30 12:48:05
【问题描述】：

我正在尝试使用 delayed_job 来使用 Sqlite3 安排任务，看起来 apache 无法读取我的 production.sqlite3 文件。

这是我的database.yml：

production:
  adapter: sqlite3
  database: db/production.sqlite3
  pool: 5
  timeout: 5000

这是我遇到的错误（在 log/production.log 中）：

ActiveRecord::StatementInvalid (SQLite3::CantOpenException: unable to open database file:)

我已经运行了RAILS_ENV=production rake db:create 和RAILS_ENV=production rake db:migrate。 db/production.sqlite3 文件存在，db 目录及其所有子文件夹归 apache:apache 所有，这是 apache 运行的对象。我在 Amazon EC2 上使用 Phusion Passenger。

【问题讨论】：

我切换到使用 PostgreSQL，它似乎运行良好。我仍然不知道为什么 SQLite 3 不起作用。
不。我放弃了，改用 PostgreSQL。
当您使用 Phusion Passenger 时，为什么用户 apache:apache 应该读取数据库文件？你有没有检查过文件是否在生产中-> db/production.sqlite3？
@awenkhh 文件实际存在。

标签： sql ruby-on-rails ruby-on-rails-3 sqlite amazon-ec2

【解决方案1】：

SQLLite 通过让 Rails 进程写入 Rails 目录树中的系统文件来工作。 Rails 进程归 Apache 所有，默认情况下设置用户“apache”和组“apache”。要使其正常工作，您需要向 /db 目录上的 apache 用户或组授予写入权限。

或

将 apache 配置为与已经拥有该目录的 write 权限的组一起运行。一个好的策略是创建一组可能需要访问不同位置的各种进程——例如，我有一个“部署者”组，用户执行发布将是该组的一部分，以及 apache 实例。我通常发现拥有一个包含各种进程和登录用户的组可以让生活更轻松（例如，查看服务器日志）、编写上传文件或缓存文件等。

与/或

使用真正的数据库服务器，如 PostgreSQL 或 MySQL——它们之所以有效，是因为它们是管理自己文件的自己的进程。 Rails 进程（在您的情况下为 apache）连接到 Unix 端口上的数据库服务器进程。每个服务器进程只安全地管理它知道的文件。

SQLLite 很容易上手——超级简单且开销低，但很快您就需要在生产环境中运行常规数据库服务器。然后你很快就会发现 SQLLite 和其他的东西并不完全相同，此时你应该在你的开发机器上安装相同的数据库服务器。

【讨论】：

我去了（在 gem 的 test 文件夹中的一个虚拟应用程序上），发现 db/ 完全丢失了。 mkdir db 为我修好了。

【解决方案2】：

这是因为 nginx 创建了 www-data 用户，而该用户没有读取 sqlite3 文件和您的应用程序的权限...

你需要运行命令：

1.sudo chown -R www-data:www-data rails_project/

2.sudo chmod -R 777 rails_project/

并检查您是否在生产模式下启动了您的应用。

【讨论】：

这是一个完全的安全失败，请绝不 chmod 777您的文件在生产服务器中。阅读@Tom Harrison Jr 的答案。
@jperelli 644 ?

【解决方案3】：

在所有内容都归 root 所有的应用中遇到了这个问题。

这就是我得到解决的方法。

root@se785fall16:/var/www/auth_whateveryousay# chmod -R 0777 db/


root@se785fall16:/var/www/auth_whateveryousay# ls -lad *
drwxr-xr-x 11 root root  4096 Nov 27 17:23 app
drwxr-xr-x  2 root root  4096 Nov 27 17:23 bin
drwxr-xr-x  5 root root  4096 Nov 27 17:23 config
-rw-r--r--  1 root root   130 Nov 27 17:23 config.ru
drwxrwxrwx  3 root root  4096 Nov 27 17:33 db
-rw-r--r--  1 root root   879 Nov 27 17:23 Gemfile
-rw-r--r--  1 root root  6367 Nov 27 17:24 Gemfile.lock
drwxr-xr-x  4 root root  4096 Nov 27 17:23 lib
drwxr-xr-x  2 root root  4096 Nov 27 17:25 log
drwxr-xr-x  2 root root  4096 Nov 27 17:23 public
-rw-r--r--  1 root root   227 Nov 27 17:23 Rakefile
-rw-r--r--  1 root root   898 Nov 27 17:23 README
-rw-r--r--  1 root root 26632 Nov 27 17:23 README.textile
drwxr-xr-x  6 root root  4096 Nov 27 17:23 spec
drwxrwxrwx  5 root root  4096 Nov 27 17:25 tmp
drwxr-xr-x  3 root root  4096 Nov 27 17:23 vendor

底线是：这是premssions问题，您需要确保拥有该应用程序的人无论是root还是非root，您只需要授予该用户对正在使用的数据库的读写权限@ 987654322@。调整它以适合您自己的安全级别。

【讨论】：

这是一个完全的安全失败，请绝不 chmod 777您的文件在生产服务器中。阅读@Tom Harrison Jr 的答案。
@jperelli 感谢您的反馈 - 这里的重点是我们只需要更改受影响文件夹“db”而不是整个应用程序文件夹“Rails 项目”的权限。在答案的最后，我提到了“调整这个以适应您自己的安全级别”，这暗示了您所说的。
好的，请在回答之前先强调安全性，以便人们在应用您的解决方案时要小心。
@jperelli。我写这个答案的唯一原因是因为 1) sudo chmod -R 777 rails_project/ 太宽泛，可能更具灾难性 2) sudo chown -R www-data:www-data 可能会产生误导，我不需要这样做就我而言。你对安全失败的事情是绝对正确的。