部署Django至Apache遇Operational Error：无法打开数据库文件

Hey there, let's break down why you're still hitting that "unable to open database file" error even after adjusting permissions. You've covered the basics, so let's dive into the less obvious (but super common) culprits:

1. Ensure all parent directories are accessible to Apache #

SQLite doesn't just need write access to the database file and its immediate folder—it needs execute permission on every parent directory leading to /home/wger/db/ to traverse into it.

First, check the permissions on /home/wger/ (the parent of your db folder):

ls -ld /home/wger/

Look for the "group" (g) permissions—you should see an x (execute) for the www-data group. If not, fix it with:

# Grant execute access to www-data group on /home/wger/
sudo chgrp www-data /home/wger/
sudo chmod g+x /home/wger/

2. Double-check your Django settings.py database path #

It's easy to accidentally use a relative path instead of an absolute one. Apache runs from a different working directory than your local dev environment, so relative paths will break.

Open your settings.py and confirm the DATABASES section uses the full absolute path:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': '/home/wger/db/database.sqlite',  # Make sure this is absolute!
    }
}

If you were using something like ./db/database.sqlite, that's the problem—replace it with the full path.

3. Check SELinux (critical for RHEL/CentOS/Debian systems) #

SELinux is often the hidden culprit here. Even if file permissions are correct, SELinux will block Apache from accessing files outside its default allowed paths.

First, test if SELinux is causing the issue by temporarily disabling it:

sudo setenforce 0

Restart Apache and try accessing your site. If the error goes away, set the correct SELinux context for your database directory (then re-enable SELinux for security):

# Label the db directory as accessible by Apache for read/write
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/home/wger/db(/.*)?"
# Apply the new context
sudo restorecon -Rv /home/wger/db/
# Re-enable SELinux
sudo setenforce 1

4. Confirm Apache is running as www-data #

Some Linux distributions use a different user/group for Apache (e.g., apache on RHEL/CentOS, wwwrun on openSUSE). Verify the user with:

# Check Apache's run user/group from env vars
cat /etc/apache2/envvars | grep -E "APACHE_RUN_USER|APACHE_RUN_GROUP"
# Or check running processes
ps aux | grep apache

If the user isn't www-data, adjust your chown/chgrp commands to use the correct group instead.

5. Verify the SQLite file isn't locked or corrupted #

Rare, but possible: another process might be holding a lock on the database, or the file could be corrupted.

First, make a backup:

cp /home/wger/db/database.sqlite /home/wger/db/database_backup.sqlite

Then try opening the file directly with SQLite:

sqlite3 /home/wger/db/database.sqlite

Run .tables in the SQLite prompt—if it lists your tables, the file is intact. If you get an error, restore from your backup or reinitialize the database.

Start with checking the parent directory permissions and SELinux first—those are the most frequent fixes for this exact scenario. Let me know if any of these resolve your issue!

内容的提问来源于stack exchange，提问作者OBX