Repository navigation
[BUG] Docker starts "successfully" and loops forever when sqlite database is corrupt #100
Description
Activity
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
- changed the title
[-][BUG] Docker does not fail to start when sqlite database is corrupt[/-][+][BUG] Docker starts "successfully" and loops forever when sqlite database is corrupt[/+]on Feb 8, 2026 I have the same issue, same Unraid version and SyncThing version. It just stopped working over the weekend after the Unraid parity check
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
Issue is still ongoing. If this is the wrong place to report it, let me know.
If the app fails, the supervisor attempts to restart it.
If you want the container to stop instead, you can probably do it via healthchecks that you can add.
But it's not going to help you in any case if the database is corrupt.
You should restore from a backup
Yes, I want the container to stop instead of the supervisor retrying forever.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
when will this be fixed
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
Not sure if this is the same issue - I am having the problem of the SQLite DB corrupting every so many weeks (error database disk image is malformed (11), too). I cannot call the WebUI, so I suppose it is in said loop. I do not get any notification, so different file versions build up. When I delete the DB folder, the DB is rebuilt, but because of the delay, I get many sync conflicts. This is affecting useability of Syncthing as a productive tool.
I am not too savvy with the details, but if this is the same error - what do you need to fix it rather than leaving it as stale? How can I contribute?
If you're asking how we can stop the database corruptions, we can't, hard or forced shutdowns are going to cause data corruption. What users should have in place is to make sure they're taking working backups of sync thing itself.
Ideally of course, database corruption should not happen in the first place - true. I am not sure why this happens so regularly, and if something can be done about it.
But when the sync function is broken, and there is no notification, you get multiple file versions that you have to clean or consolidate afterwards. I will have a look how to restore the Docker DB backup (instead of rebuilding the index) - Maybe this would avoid some of the sync conflicts.
I am not sure if there is a way to notify users or the admin about the problem before too many file versions diverge.
I have the same issue. I have two UnRaid servers that are mirrored for backup. Every few weeks, one of the databases gets malformed and Syncthing just dies. Due to my data foot print (30TB), I have yet to complete a initial Sync after 4 months of trying. There are no hard shutdowns or hardware crashes.
In the Syncthing support forums, they are critical of the database backend used in the Docker version of Syncthing:
"Not sure it’s the root cause, but it won’t help - you’re using a build that uses the much-less-tested and lower-performance Go port of SQLite. You really want to use a better build, e.g. one of ours."
So, I guess the million peso question is "Is my usage case of a mirror consisting of 30TB+ of data too much for the Linuxserver Docker version of Syncthing?"
If "yes" then what is a better tool? I had paired TrueNAS Scale boxes for a year and never had an issue. with file synching.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
"Not sure it’s the root cause, but it won’t help - you’re using a build that uses the much-less-tested and lower-performance Go port of SQLite. You really want to use a better build, e.g. one of ours."
I have no idea what that's about.
We compile their static go binary and stick it in an alpine image, which seems to be exactly what they're doing with theirs:
https://github.com/syncthing/syncthing/blob/main/Dockerfile#L20
https://github.com/syncthing/syncthing/blob/main/Dockerfile#L29
https://github.com/syncthing/syncthing/blob/main/Dockerfile#L46Also with regards to corrupt databases, the most common cause of that is putting the database files (/config folder of the container) on a non-native file system, which can be a remote mount like smb/nfs, or one that goes through an abstraction layer like fuse or wsl's win ntfs mounts (unraid does this with fuse mounts for their /mnt/user paths)
Is there an existing issue for this?
Current Behavior
I had a hard container shutdown (on Unraid) and my sqlite database got corrupted somehow. When the container restarted it started "successfully" but actually was looping this error forever:
2026-02-03 10:38:41 INF syncthing v2.0.14 "Hafnium Hornet" (go1.24.12 linux-amd64) root@buildkitsandbox 2026-02-03 09:33:54 UTC [modernc-sqlite, noupgrade] (log.pkg=main) 2026-02-03 10:38:41 ERR Error opening database (error="openbase (PRAGMA optimize = 0x10002): database disk image is malformed (11)" log.pkg=main)Expected Behavior
Container should fail to start instead of getting stuck in an error loop.
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation
Container logs