[GH-ISSUE #377] file is not a database (26) error #248

New issue

Closed

opened 2026-03-15 13:26:25 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 13:26:25 +03:00

Owner

Originally created by @Kqirk on GitHub (Oct 21, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/377

Hi,

I was using mailpit v1.19 since 4 months ago without issues when I was suddenly hit with this error:
level=error msg="[db] file is not a database (26)"

Here are the logs based on chronological order:
time="2024/10/20 01:21:37" level=debug msg="[db] opening database /db/database.db"
time="2024/10/20 01:22:34" level=debug msg="[db] auto-pruned 1 messages in 166.14908ms"
time="2024/10/20 01:22:37" level=error msg="[db] file is not a database (26)"
[db] got terminated signal, shutting down

I deployed Mailpit using AWS ECS, and MP_DATABASE is set to /db/database.db

Mailpit is working after I redeployed using image tag 1.20.7 (with the emails retained), however, does anyone have any clues as to why this happened, I do not see a fix specific to this in the changelog

Thank you for your time

Originally created by @Kqirk on GitHub (Oct 21, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/377 Hi, I was using mailpit v1.19 since 4 months ago without issues when I was suddenly hit with this error: level=error msg="[db] file is not a database (26)" Here are the logs based on chronological order: `time="2024/10/20 01:21:37" level=debug msg="[db] opening database /db/database.db"` `time="2024/10/20 01:22:34" level=debug msg="[db] auto-pruned 1 messages in 166.14908ms"` `time="2024/10/20 01:22:37" level=error msg="[db] file is not a database (26)"` `[db] got terminated signal, shutting down` I deployed Mailpit using AWS ECS, and MP_DATABASE is set to /db/database.db Mailpit is working after I redeployed using image tag 1.20.7 (with the emails retained), however, does anyone have any clues as to why this happened, I do not see a fix specific to this in the changelog Thank you for your time

kerem closed this issue

2026-03-15 13:26:40 +03:00

kerem commented

2026-03-15 13:26:50 +03:00

Author

Owner

@axllent commented on GitHub (Oct 21, 2024):

Hi @Kqirk. That is an odd thing to happen and not one that has ever been reported here. The error file is not a database is a default SQLite error meaning it tried to open (or read) the database file however the file was not detected as a valid SQLite database file.

The reason this happened is the mystery though. Normally it would indicate that the database file was corrupted (eg: overwritten) by another process, however then it would not have started up again if the file was still corrupted.

Is /db a mounted Docker volume, and could the connection to this have been broken (eg: disconnected EFS?) while the container was running? Redeploying would have then remounted the volume which would then have resumed its previous state.

Between v1.19 and 1.20.7 there have been a number of module updates including the SQLite library, so it is possible this was a bug fixed since then, although Mailpit uses a Go port of SQLite which is kind-of "converted" from the original C to Go so this would be very difficult to trace. I think however that it's far more likely that there was a glitch between the ECS and the /db/ volume (assuming it is a volume).

@axllent commented on GitHub (Oct 21, 2024): Hi @Kqirk. That is an odd thing to happen and not one that has ever been reported here. The error `file is not a database` is a default SQLite error meaning it tried to open (or read) the database file however the file was not detected as a valid SQLite database file. The reason this happened is the mystery though. Normally it would indicate that the database file was corrupted (eg: overwritten) by another process, however then it would not have started up again if the file was still corrupted. Is `/db` a mounted Docker volume, and could the connection to this have been broken (eg: disconnected EFS?) while the container was running? Redeploying would have then remounted the volume which would then have resumed its previous state. Between v1.19 and 1.20.7 there have been a number of module updates including the SQLite library, so it is possible this was a bug fixed since then, although Mailpit uses a [Go port](https://gitlab.com/cznic/sqlite) of SQLite which is kind-of "converted" from the original C to Go so this would be very difficult to trace. I think however that it's far more likely that there was a glitch between the ECS and the `/db/` volume (assuming it is a volume).

kerem commented

2026-03-15 13:26:55 +03:00

Author

Owner

@Kqirk commented on GitHub (Oct 21, 2024):

Hi axllent,

Thank you so much for the quick response.
The volume is indeed a mounted EFS on /db to the container, I'm confused myself as I managed to ssh into the container and verify that I could see the /db path and database.db, and if the file was corrupted, the latest deploy wouldn't have been able to read and display old emails as well
I also saw on the console that the EFS was mounted without errors, and utilization metrics didn't show any spikes or high throughput/usage (including ECS cpu and mem)
I'll do some more digging on my end on the EFS front, if this occurs again or I find the reason, I'll update this issue.

Thank you so much for the response again and thank you for Mailpit, using Mailpit has solved an ongoing issue for us. 🫡

@Kqirk commented on GitHub (Oct 21, 2024): Hi axllent, Thank you so much for the quick response. The volume is indeed a mounted EFS on /db to the container, I'm confused myself as I managed to ssh into the container and verify that I could see the /db path and database.db, and if the file was corrupted, the latest deploy wouldn't have been able to read and display old emails as well I also saw on the console that the EFS was mounted without errors, and utilization metrics didn't show any spikes or high throughput/usage (including ECS cpu and mem) I'll do some more digging on my end on the EFS front, if this occurs again or I find the reason, I'll update this issue. Thank you so much for the response again and thank you for Mailpit, using Mailpit has solved an ongoing issue for us. 🫡

kerem commented

2026-03-15 13:27:00 +03:00

Author

Owner

@axllent commented on GitHub (Oct 21, 2024):

No problem, I'm glad to help (or at least point you in the right direction)! Also really glad you hear that Mailpit is useful to you 👍

@axllent commented on GitHub (Oct 21, 2024): No problem, I'm glad to help (or at least point you in the right direction)! Also really glad you hear that Mailpit is useful to you 👍