Rails: SQLite3::CantOpenException: unable to open database file

Question

I'm trying to use delayed_job to schedule tasks using Sqlite3, and it looks like apache isn't able to read my production.sqlite3 file.

Here's my database.yml:

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

Here's the error I am getting (in log/production.log):

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

I have run RAILS_ENV=production rake db:create and RAILS_ENV=production rake db:migrate. The db/production.sqlite3 file exists, and the db directory and all its subfolders are owned by apache:apache, which is who apache runs as. I'm using Phusion Passenger on Amazon EC2.

Solution 1

SQLLite works by having the Rails process write to a system file within the Rails directory tree. The Rails process is owned by Apache, which sets a user "apache" and a group "apache" by default. To make it work you would need to give write permissions to the apache user or group on the /db directory.

OR

Configure apache to run with a group already having write permissions to the directory. A good strategy is to create a group of the various processes that may need access to various locations -- for example I have a "deployer" group that the user doing releases would be part of, along with the apache instance. I typically find that having a group that the various process and login users are part of makes life easier (e.g. for looking at server logs), writing uploads or cached files, etc.

AND/OR

Use a real database server like PostgreSQL or MySQL -- they work because they are their own processes that manage their own files. The Rails process (apache, in your case) connects to the database server process on a Unix port. Each server process securely manages only files it knows about.

SQLLite is fine to get started -- super easy and low overhead, but very soon you'll need to run a regular database server on production. And then you'll soon find that things aren't exactly the same between SQLLite and the others, at which point you should just install the same database server on your dev machine.

Solution 2

It's because nginx create www-data user, and this user don't have a previlegues to read sqlite3 file and your app...

You need to run commands:

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

2.sudo chmod -R 777 rails_project/

And check that you kick off your app in production mode.

Comments

[jperelli]

This is a complete security fail, please NEVER chmod 777 your files in a production server. Read @Tom Harrison Jr answer.

[jperelli]

This is a complete security fail, please NEVER chmod 777 your files in a production server. Read @Tom Harrison Jr answer.

[z atef]

@jperelli thanks for the feedback - The point here is that we only need to change permissions on the impacted folder "db" and not the whole app-folder"Rails project". At the end of the answer, I mentioned " Tweak this to fit your own security level" which implies what you said.

[jperelli]

Ok, please put emphasis on security before in your answer, so people are aware to be cautious when applying your solution.

[z atef]

@jperelli. The only reason I wrote this answer is because 1) sudo chmod -R 777 rails_project/ was too broad and can be more catastrophic 2) sudo chown -R www-data:www-data can be misleading and I didn't need to do it in my case. You are absolutely right about the security fail thing.

[bmalets]

@jperelli 644 ?

[PJSCopeland]

I went to do this (on a dummy app in a gem's test folder) and found that db/ was missing entirely. mkdir db fixed it for me.