#744 - [GH-ISSUE #1070] 500 Server error - unable to open database file - starred/healthchecks

kerem commented

2026-02-25 23:43:26 +03:00

Owner

Originally created by @ric-m on GitHub (Oct 12, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1070

Fresh install of HeathchecksUI on Raspberry Pi 64 bit OS (Bookworm) running in docker container.
I can get to the login screen but after that I get a 500 Server error.
Turning on debug I get the following output:

OperationalError
       at /accounts/login/
       unable to open database file
  
Request Method: | POST
-- | --
http://192.168.1.55:8010/accounts/login/
5.1.1
OperationalError
unable to open database file
/usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py, line 200, in get_new_connection
hc.accounts.views.login
/usr/local/bin/uwsgi
3.12.5
['.',  '',  '/usr/local/lib/python312.zip',  '/usr/local/lib/python3.12',  '/usr/local/lib/python3.12/lib-dynload',  '/usr/local/lib/python3.12/site-packages']
Sat, 12 Oct 2024 04:31:54 +0000

followed by a lot of debug output, including:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py", line 279, in ensure_connection
    self.connect()
    ^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py", line 256, in connect
    self.connection = self.get_new_connection(conn_params)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py", line 200, in get_new_connection
    conn = Database.connect(**conn_params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The above exception (unable to open database file) was the direct cause of the following exception:
  File "/usr/local/lib/python3.12/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
               ^^^^^^^^^^^^^^^^^^^^^

Note: the external:internal port mapping has been changed to 8010:8000 to avoid conflict
Note: healthchecks reports "unhealthy" status

I'd really appreciate someone being able to walk me through the checks I need to make to resolve the issue.
Many thanks,
Ric

Originally created by @ric-m on GitHub (Oct 12, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1070 Fresh install of HeathchecksUI on Raspberry Pi 64 bit OS (Bookworm) running in docker container. I can get to the login screen but after that I get a 500 Server error. Turning on debug I get the following output: ``` OperationalError at /accounts/login/ unable to open database file Request Method: | POST -- | -- http://192.168.1.55:8010/accounts/login/ 5.1.1 OperationalError unable to open database file /usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py, line 200, in get_new_connection hc.accounts.views.login /usr/local/bin/uwsgi 3.12.5 ['.', '', '/usr/local/lib/python312.zip', '/usr/local/lib/python3.12', '/usr/local/lib/python3.12/lib-dynload', '/usr/local/lib/python3.12/site-packages'] Sat, 12 Oct 2024 04:31:54 +0000 ``` followed by a lot of debug output, including: ``` Traceback (most recent call last): File "/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py", line 279, in ensure_connection self.connect() ^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner return func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/django/db/backends/base/base.py", line 256, in connect self.connection = self.get_new_connection(conn_params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/django/utils/asyncio.py", line 26, in inner return func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py", line 200, in get_new_connection conn = Database.connect(**conn_params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above exception (unable to open database file) was the direct cause of the following exception: File "/usr/local/lib/python3.12/site-packages/django/core/handlers/exception.py", line 55, in inner response = get_response(request) ^^^^^^^^^^^^^^^^^^^^^ ``` **Note**: the external:internal port mapping has been changed to 8010:8000 to avoid conflict **Note**: healthchecks reports "unhealthy" status I'd really appreciate someone being able to walk me through the checks I need to make to resolve the issue. Many thanks, Ric

kerem closed this issue

2026-02-25 23:43:26 +03:00

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 14, 2024):

Thanks for the report.

How does the command line for starting the container look?

@cuu508 commented on GitHub (Oct 14, 2024): Thanks for the report. How does the command line for starting the container look?

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@ric-m commented on GitHub (Oct 15, 2024):

Hello,
All my docker containers are configured via docker compose. Strating a container is therefore nothing more than the usual docker compose up -d.

I've included an anonymised compose.yaml file at the end for completeness.

What I can see is the following screen after trying to log in:

OperationalError at /accounts/login/
unable to open database file
Request Method: POST
Request URL: http://192.168.1.55:8010/accounts/login/
Django Version: 5.1.1
Exception Type: OperationalError
Exception Value:
unable to open database file
Exception Location: /usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py, line 200, in get_new_connection
Raised during: hc.accounts.views.login
Python Executable: /usr/local/bin/uwsgi
Python Version: 3.12.5
Python Path:
['.',
'',
'/usr/local/lib/python312.zip',
'/usr/local/lib/python3.12',
'/usr/local/lib/python3.12/lib-dynload',
'/usr/local/lib/python3.12/site-packages']
Server time: Tue, 15 Oct 2024 06:38:28 +0000

There doesn't appear to be a file at /usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py and yet the error is reported at line 200....

compose.yaml:

services:
  healthchecks:
    image: healthchecks/healthchecks:latest
    container_name: healthchecks
    restart: unless-stopped

    ports:
      - 8010:8000

    volumes:
      - ../../volumes/healthchecks/healthchecks-data:/data

    networks:
      - pi_net

    environment:
      # set this to the IP address of the RPI device
      - ALLOWED_HOSTS=localhost,192.168.1.55, raspberrypi.local
      # the following port must be the same as the external port defined above.
      - SITE_ROOT=http://localhost:8010
      - SUPERUSER_EMAIL=someone@realmailserver
      - SUPERUSER_PASSWORD=realpassword
      - DB=sqlite
      - DB_NAME=/data/hc.sqlite
      - DEBUG=True
      - DEFAULT_FROM_EMAIL=anotheruser@realmailserver
      - EMAIL_HOST_PASSWORD=realpassword
      - EMAIL_HOST_USER=realusername@realmailserver
      # Next 2 entries: use port 465 for SSl; 587 for TLS:
      - EMAIL_PORT=587
      - EMAIL_USE_TLS=True
      - SECRET_KEY=12345

networks:
  pi_net:
    external: true

It would not surprise me if theres somewthing amiss with that configration..

Regards,
Ric

@ric-m commented on GitHub (Oct 15, 2024): Hello, All my docker containers are configured via docker compose. Strating a container is therefore nothing more than the usual `docker compose up -d`. I've included an anonymised compose.yaml file at the end for completeness. What I can see is the following screen after trying to log in: > OperationalError at /accounts/login/ > unable to open database file > Request Method: POST > Request URL: http://192.168.1.55:8010/accounts/login/ > Django Version: 5.1.1 > Exception Type: OperationalError > Exception Value: > unable to open database file > Exception Location: /usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py, line 200, in get_new_connection > Raised during: hc.accounts.views.login > Python Executable: /usr/local/bin/uwsgi > Python Version: 3.12.5 > Python Path: > ['.', > '', > '/usr/local/lib/python312.zip', > '/usr/local/lib/python3.12', > '/usr/local/lib/python3.12/lib-dynload', > '/usr/local/lib/python3.12/site-packages'] > Server time: Tue, 15 Oct 2024 06:38:28 +0000 There doesn't appear to be a file at `/usr/local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py` and yet the error is reported at line 200.... **compose.yaml:** ``` services: healthchecks: image: healthchecks/healthchecks:latest container_name: healthchecks restart: unless-stopped ports: - 8010:8000 volumes: - ../../volumes/healthchecks/healthchecks-data:/data networks: - pi_net environment: # set this to the IP address of the RPI device - ALLOWED_HOSTS=localhost,192.168.1.55, raspberrypi.local # the following port must be the same as the external port defined above. - SITE_ROOT=http://localhost:8010 - SUPERUSER_EMAIL=someone@realmailserver - SUPERUSER_PASSWORD=realpassword - DB=sqlite - DB_NAME=/data/hc.sqlite - DEBUG=True - DEFAULT_FROM_EMAIL=anotheruser@realmailserver - EMAIL_HOST_PASSWORD=realpassword - EMAIL_HOST_USER=realusername@realmailserver # Next 2 entries: use port 465 for SSl; 587 for TLS: - EMAIL_PORT=587 - EMAIL_USE_TLS=True - SECRET_KEY=12345 networks: pi_net: external: true ``` It would not surprise me if theres somewthing amiss with that configration.. Regards, Ric

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 15, 2024):

Perhaps there's a permissions issue with ../../volumes/healthchecks/healthchecks-data?

If you drop into a shell inside the healthchecks container, can you create files in /data?

@cuu508 commented on GitHub (Oct 15, 2024): Perhaps there's a permissions issue with `../../volumes/healthchecks/healthchecks-data`? If you drop into a shell inside the healthchecks container, can you create files in `/data`?

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@BuethSam commented on GitHub (Oct 15, 2024):

I just had the same problem.
I checkt that docker image is running as user 999 with dc exec healthchecks id
I set the ownership of the directory to 999:999 and that fixed it.

@BuethSam commented on GitHub (Oct 15, 2024): I just had the same problem. I checkt that docker image is running as user _999_ with `dc exec healthchecks id` I set the ownership of the directory to `999:999` and that fixed it.

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@ric-m commented on GitHub (Oct 15, 2024):

Perhaps there's a permissions issue with ../../volumes/healthchecks/healthchecks-data?

If you drop into a shell inside the healthchecks container, can you create files in /data?

Well now... that's very interesting here's the result:

$ **sudo docker exec -it healthchecks /bin/bash**
hc@586a378e96a8:/opt/healthchecks$ **ls**
CHANGELOG.md	 LICENSE    SECURITY.md  hc	    mypy.ini	      search.db  static-collected
CONTRIBUTING.md  README.md  docker	 manage.py  requirements.txt  static	 templates
hc@586a378e96a8:/opt/healthchecks$ **cd docker**
hc@586a378e96a8:/opt/healthchecks/docker$ **ls**
Dockerfile  README.md  docker-compose.yml  fetchstatus.py  uwsgi.ini
hc@586a378e96a8:/opt/healthchecks/docker$

no data folder... also
/healthchecks-data is empty
and aren't the container files mapped to /var/lib/docker/overlay2/.. ?

I've also just added GUID / PGID = 1000 (me) and then 0 (root). Again, same as before, "unable to open database file".

Regards,
Ric

@ric-m commented on GitHub (Oct 15, 2024): > Perhaps there's a permissions issue with `../../volumes/healthchecks/healthchecks-data`? > > If you drop into a shell inside the healthchecks container, can you create files in `/data`? Well now... that's very interesting here's the result: ``` $ **sudo docker exec -it healthchecks /bin/bash** hc@586a378e96a8:/opt/healthchecks$ **ls** CHANGELOG.md LICENSE SECURITY.md hc mypy.ini search.db static-collected CONTRIBUTING.md README.md docker manage.py requirements.txt static templates hc@586a378e96a8:/opt/healthchecks$ **cd docker** hc@586a378e96a8:/opt/healthchecks/docker$ **ls** Dockerfile README.md docker-compose.yml fetchstatus.py uwsgi.ini hc@586a378e96a8:/opt/healthchecks/docker$ ``` no data folder... also `/healthchecks-data` is empty and aren't the container files mapped to `/var/lib/docker/overlay2/..` ? I've also just added GUID / PGID = 1000 (me) and then 0 (root). Again, same as before, "unable to open database file". Regards, Ric

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@ric-m commented on GitHub (Oct 15, 2024):

I just had the same problem. I checkt that docker image is running as user 999 with dc exec healthchecks id I set the ownership of the directory to 999:999 and that fixed it.

I tried that and yes, my UID/GID, etc are all 999. Butit changed nothing. But see my next post.
Cheers,
Ric

@ric-m commented on GitHub (Oct 15, 2024): > I just had the same problem. I checkt that docker image is running as user _999_ with `dc exec healthchecks id` I set the ownership of the directory to `999:999` and that fixed it. I tried that and yes, my UID/GID, etc are all 999. Butit changed nothing. But see my next post. Cheers, Ric

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@ric-m commented on GitHub (Oct 15, 2024):

Well, this is the most curious thing.
I have been checking other docker compose files and came across this:

https://docs.linuxserver.io/images/docker-healthchecks/

I pretty much copied the file verbatim an added a superuser/passwd, etc, nothing more apart from a target IP of 192.168.1.55 and port 8000.
Using those credentials I could log in and accessed the screen where it says "My First Check".

So I guess that's it. Why the one should work and not the other I still have to find out. I intend to add-in, incrementally, more of the parameters from my original compose.yaml file to see if there is a specific directive that breaks it.

For reference, here is the compose.yaml from linuxserver, anonymised:

services:
  healthchecks:
    image: lscr.io/linuxserver/healthchecks:latest
    container_name: healthchecks
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - SITE_ROOT=**192.168.1.55**
      - SITE_NAME="**My HC Site Name for Testing**"
      - SUPERUSER_EMAIL=me@mygenuine emailaddress
      - SUPERUSER_PASSWORD=mygenuinepassword
      - ALLOWED_HOSTS= #optional
      - APPRISE_ENABLED=False #optional
      - CSRF_TRUSTED_ORIGINS= #optional
      - DEBUG=True #optional
      - DEFAULT_FROM_EMAIL= #optional
      - EMAIL_HOST= #optional
      - EMAIL_PORT= #optional
      - EMAIL_HOST_USER= #optional
      - EMAIL_HOST_PASSWORD= #optional
      - EMAIL_USE_TLS= #optional
      - INTEGRATIONS_ALLOW_PRIVATE_IPS= #optional
      - PING_EMAIL_DOMAIN= #optional
      - RP_ID= #optional
      - SECRET_KEY= #optional
      - SITE_LOGO_URL= #optional
    volumes:
      - /path/to/healthchecks/config:/config
    ports:
      - 8000:8000
      - 2525:2525 #optional
    restart: unless-stopped

The first thing I'm going to do is change the location of the volumes file to be consistent with all the other containers.
Thanks all for your comments. I am pretty much a newcomer to linux, Raspberry Pi, docker, etc but I'm enjoying the learning from people who know a lot more than me...
I also need to get to know how to use the software.
Regards,
Ric

@ric-m commented on GitHub (Oct 15, 2024): Well, this is the most curious thing. I have been checking other docker compose files and came across this: > https://docs.linuxserver.io/images/docker-healthchecks/ I pretty much copied the file verbatim an added a superuser/passwd, etc, nothing more apart from a target IP of 192.168.1.55 and port 8000. Using those credentials I could log in and accessed the screen where it says "My First Check". So I guess that's it. Why the one should work and not the other I still have to find out. I intend to add-in, incrementally, more of the parameters from my original compose.yaml file to see if there is a specific directive that breaks it. For reference, here is the compose.yaml from linuxserver, anonymised: ``` services: healthchecks: image: lscr.io/linuxserver/healthchecks:latest container_name: healthchecks environment: - PUID=1000 - PGID=1000 - TZ=Etc/UTC - SITE_ROOT=**192.168.1.55** - SITE_NAME="**My HC Site Name for Testing**" - SUPERUSER_EMAIL=me@mygenuine emailaddress - SUPERUSER_PASSWORD=mygenuinepassword - ALLOWED_HOSTS= #optional - APPRISE_ENABLED=False #optional - CSRF_TRUSTED_ORIGINS= #optional - DEBUG=True #optional - DEFAULT_FROM_EMAIL= #optional - EMAIL_HOST= #optional - EMAIL_PORT= #optional - EMAIL_HOST_USER= #optional - EMAIL_HOST_PASSWORD= #optional - EMAIL_USE_TLS= #optional - INTEGRATIONS_ALLOW_PRIVATE_IPS= #optional - PING_EMAIL_DOMAIN= #optional - RP_ID= #optional - SECRET_KEY= #optional - SITE_LOGO_URL= #optional volumes: - /path/to/healthchecks/config:/config ports: - 8000:8000 - 2525:2525 #optional restart: unless-stopped ``` The first thing I'm going to do is change the location of the volumes file to be consistent with all the other containers. Thanks all for your comments. I am pretty much a newcomer to linux, Raspberry Pi, docker, etc but I'm enjoying the learning from people who know a lot more than me... I also need to get to know how to use the software. Regards, Ric

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 16, 2024):

@ric-m

no data folder... also /healthchecks-data is empty

You are looking for the data folder inside /opt/healthchecks and inside /opt/healthchecks/docker.

But your docker-compose file mounts the volume on a folder inside the root directory: /data. It also instructs healthchecks to look for the sqlite database there:

DB_NAME=/data/hc.sqlite

@cuu508 commented on GitHub (Oct 16, 2024): @ric-m > no data folder... also /healthchecks-data is empty You are looking for the data folder inside `/opt/healthchecks` and inside `/opt/healthchecks/docker`. But your docker-compose file mounts the volume on a folder inside the root directory: `/data`. It also instructs healthchecks to look for the sqlite database there: ``` DB_NAME=/data/hc.sqlite ```

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@crazybob1215 commented on GitHub (Oct 18, 2024):

I'm seeing this same error. My volume mapping looks like this:

/opt/stacks/healthchecks/db-data:/var/lib/postgresql/data

From a fresh install, the external folder permissions look like this:

drwx------ 19 999 root 4096 Oct 18 11:59 db-data

If I change the permissions to be 999:999, it changes to:

drwx------ 19 999 docker 4096 Oct 18 11:59 db-data

But fixing the group doesn't seem to matter since it's not getting read or write anyway. I've tried manually adding read & write for the group, but when I restart the container it is set back to no permissions for the group.

Moving into the container, if I try to follow the internal volume mapping, the postgresql folder isn't being created, and permissions for the /var directory are all root.

hc@53a12a863f0c:/opt/healthchecks$ ls -al /var/lib
total 32
drwxr-xr-x 1 root root 4096 Aug 12 00:00 .
drwxr-xr-x 1 root root 4096 Aug 12 00:00 ..
drwxr-xr-x 1 root root 4096 Sep 4 07:20 apt
drwxr-xr-x 1 root root 4096 Sep 4 07:20 dpkg
drwxr-xr-x 2 root root 4096 Mar 29 2024 misc
drwxr-xr-x 2 root root 4096 Aug 12 00:00 pam
-rw-r--r-- 1 root root 94 Aug 12 00:00 shells.state
drwxr-xr-x 3 root root 4096 Aug 12 00:00 systemd

I'm not sure what I'm missing here?

@crazybob1215 commented on GitHub (Oct 18, 2024): I'm seeing this same error. My volume mapping looks like this: > /opt/stacks/healthchecks/db-data:/var/lib/postgresql/data From a fresh install, the external folder permissions look like this: > drwx------ 19 999 root 4096 Oct 18 11:59 db-data If I change the permissions to be 999:999, it changes to: > drwx------ 19 999 docker 4096 Oct 18 11:59 db-data But fixing the group doesn't seem to matter since it's not getting read or write anyway. I've tried manually adding read & write for the group, but when I restart the container it is set back to no permissions for the group. Moving into the container, if I try to follow the internal volume mapping, the postgresql folder isn't being created, and permissions for the /var directory are all root. > hc@53a12a863f0c:/opt/healthchecks$ ls -al /var/lib total 32 drwxr-xr-x 1 root root 4096 Aug 12 00:00 . drwxr-xr-x 1 root root 4096 Aug 12 00:00 .. drwxr-xr-x 1 root root 4096 Sep 4 07:20 apt drwxr-xr-x 1 root root 4096 Sep 4 07:20 dpkg drwxr-xr-x 2 root root 4096 Mar 29 2024 misc drwxr-xr-x 2 root root 4096 Aug 12 00:00 pam -rw-r--r-- 1 root root 94 Aug 12 00:00 shells.state drwxr-xr-x 3 root root 4096 Aug 12 00:00 systemd I'm not sure what I'm missing here?

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 19, 2024):

@crazybob1215 the original issue is about sqlite driver not being able to access the database file. But from your comment it seems like you are using postgresql. Are you sure you are seeing the same error?

@cuu508 commented on GitHub (Oct 19, 2024): @crazybob1215 the original issue is about sqlite driver not being able to access the database file. But from your comment it seems like you are using postgresql. Are you sure you are seeing the same error?

kerem commented

2026-02-25 23:43:26 +03:00

Author

Owner

@retifrav commented on GitHub (Oct 11, 2025):

I set the ownership of the directory to 999:999 and that fixed it.

In case someone else ends up here like me: with Docker in rootless mode the 999:999 user within the container results in 100998:100998 on the host, so I needed to change the ownership of the mapped data path on the host to those values. Of course, a crude chmod -R 777 /path/to/data would have "solved" the problem too, but that's not a good way to go about it.

Alternatively, it could have probably been solved with --user or/and UID/GID on creating the container, but I've never been able to apply those correctly.

@retifrav commented on GitHub (Oct 11, 2025): > I set the ownership of the directory to 999:999 and that fixed it. In case someone else ends up here like me: with Docker in [rootless mode](https://docs.docker.com/engine/security/rootless/) the `999:999` user within the container results in `100998:100998` on the host, so I needed to change the ownership of the mapped `data` path on the host to those values. Of course, a crude `chmod -R 777 /path/to/data` would have "solved" the problem too, but that's not a good way to go about it. Alternatively, it could have probably been solved with `--user` or/and `UID`/`GID` on creating the container, but I've never been able to apply those correctly.

Rows
Columns

[GH-ISSUE #1070] 500 Server error - unable to open database file #744