なぜCGI × SQLite3でトラブルが起きるのか？
CGI（Common Gateway Interface）でWebアプリケーションを動かす際に、SQLite3を使う場面は意外と多いですよね。軽量で扱いやすく、セットアップも簡単。でも、いざ使ってみると「データベースが開けない…」「書き込めない…」といったエラーに遭遇して、頭を抱えた経験がある方もいらっしゃるのではないでしょうか。
実はこの問題、SQLite3自体というより「ファイルのパーミッション設定」に原因があるケースがほとんどです。サーバ上で動くCGIが、正しくデータベースにアクセスできるようにするには、ちょっとしたコツが必要なんです。
よくあるエラーとその原因
- SQLite3::CantOpenException: unable to open database file
- SQLite3::ReadOnlyException: attempt to write a readonly database
これらの例外が発生した場合、「データベースファイルが見つからない」または「書き込み権限がない」ことが疑われます。CGIスクリプトがサーバ上で別ユーザー（たとえば www-data）として実行されるため、そのユーザーに適切な権限を与えないとエラーが起きてしまうのです。
まず確認すべき2つのポイント
トラブルを避けるために、以下の2点をしっかりチェックしましょう。
- データベースファイルの所有者とグループ設定
- データベースを格納しているディレクトリのパーミッション
言葉だけだとピンとこないかもしれませんので、それぞれ具体的に見ていきましょう。
① ファイルのオーナーをCGIユーザーに合わせる
サーバでCGIが動作するユーザー（多くの場合 www-data）が、データベースファイルにアクセスできるように、ファイルの所有者とグループを変更する必要があります。
たとえば、データベースファイルが db/db.sqlite3 にある場合、以下のコマンドを実行します：
chown www-data:www-data db/db.sqlite3「所有者？グループ？よくわからん！」という方、大丈夫です。これは簡単に言えば「このファイルを誰が使えるようにするか」という設定です。CGIが動いているユーザーに権限を渡してあげる、というイメージですね。
② ディレクトリのパーミッションを緩める
ファイル単体の権限を変えただけでは不十分な場合もあります。実は、データベースを置いているディレクトリにも書き込み権限が必要です。
こちらも例で説明します。ディレクトリ db にデータベースがある場合、以下のようにしてディレクトリ自体にフルアクセス権を付与する必要があります。
chmod 777 db「ちょっとパーミッション777って危ないんじゃ？」という鋭いご指摘、ごもっともです。本番環境ではもっと細かい設定が理想ですが、開発中や小規模用途であればひとまず動作確認を優先しても良いかもしれません。
気をつけたいセキュリティ面の補足
chmod 777は確かに「何でもできる」状態にしてくれるのですが、セキュリティリスクが高まる点は無視できません。外部からアクセス可能な状態になってしまうと、最悪データを抜き取られる可能性もあります。
そのため、運用フェーズに入ったら以下のような対応も検討しましょう：
- Webサーバ専用のユーザーに絞ったアクセス権の設定
- .htaccessでディレクトリへのアクセス制限
- データベースファイルの移動（公開ディレクトリ外へ）
動作確認と本番運用では、やはり求められる「慎重さ」が違いますね。
まとめ：動かないときは「誰が触ってるか」に注目！
CGIでSQLite3が動かないとき、ついコードのバグを疑いがちですが、意外と「ファイルの持ち主や権限設定」が原因だったりします。そんなときは、以下の2点をチェックしてみてください：
- データベースファイルの所有者とグループがCGIユーザーに合っているか？
- データベースを格納するディレクトリのパーミッションが適切か？
この2つを押さえておくだけで、SQLite3との付き合い方がずいぶんスムーズになりますよ。「あれ、また書き込めない…」なんてイライラから卒業しましょう！
