mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
SQLite Error <#>: 'database is locked' #7457
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @papavictor on GitHub (Oct 20, 2025).
Description of the bug
Upgrade to 10.11.0 works, as does DB migration. After restarting (and installing the newer LDAP plugin), I attempt to run a Full Library Scan. The application eventually hangs, never reaching more than ~80%, and the logs are full of "SQLite Error (5|6): 'database table is locked'" errors. At startup, I see
This doesn't seem to prevent the database from locking frequently.
Reproduction steps
What is the current bug behavior?
The application hangs and becomes entirely unresponsive. Restarting Jellyfin allows the application to proceed, but another library scan causes the same issue.
What is the expected correct behavior?
Library scan completes without issue.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
10.11.0+deb12
Specify the build version
10.11.0
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@crobibero commented on GitHub (Oct 20, 2025):
"NoLock" doesn't add any locking, please read the blog post on locking methods
https://jellyfin.org/posts/SQLite-locking
@papavictor commented on GitHub (Oct 20, 2025):
Is it possible for the user to configure a different mode of locking, say Optimistic?
@JPVenson commented on GitHub (Oct 20, 2025):
https://jellyfin.org/docs/general/administration/troubleshooting#database-locked-errors
@Kitt3120 commented on GitHub (Oct 21, 2025):
Setting the lock behaviour to Optimistic helped me get my server running again. Performance is super slow though. It takes about 7 minutes to load up the web interface main page. Another 3 minutes to get into the admin dashboard. CPU usage is at 6%, so it eats up about one of my cores. Still got 2 "database is locked" errors. Something is definitely going wrong here. But it did load eventually, so I was able to set my parallel scan task limit to 1, set the behaviour back to NoLock, and restart the container again. However, that did not change anything, performance is still bad, and still getting lock errors.
I am not on a network file system, this is local.
@JPVenson commented on GitHub (Oct 21, 2025):
zfs?
@Kitt3120 commented on GitHub (Oct 21, 2025):
Yes, I am on ZFS. I set the behaviour back to Optimistic, and kept the low parallel scan task limit of 1. It's super slow, but at least I can access the web interface. I never had this problem before updating to 10.11.0. The "database is locked" errors occur while the OptimizeDatabaseTask is running.
I'll let all the tasks finish overnight for now. Maybe the performance hit comes from the locking mechanism + all tasks running because of the container restart.
Edit: It's not just the OptimizeDatabaseTask.
@papavictor commented on GitHub (Oct 21, 2025):
My last attempt of running Optimistic with 4 threads (12 cores) got the same issue and now won't boot, despite restarting jellyfin several times. I'll have to restore from backup a 4th time and attempt another upgrade. I've never had database slowness prior to this version. I've now had several queries timeout over 10 minutes. If lowering the scan count to 1 doesn't help, I'll have to downgrade until these queries are optimized.
615secs:
673 secs:
@Casuallynoted commented on GitHub (Oct 21, 2025):
Getting a ton of "SQLite Error 6: 'database table is locked: UserData'." in my logs and locking up of the UI after the update to 10.11. Persists after several restarts.
@Kitt3120 commented on GitHub (Oct 21, 2025):
I let it run overnight, and now I can't access the web interface anymore. The login times out. Logs are full of this, but no other errors:
@appletalk commented on GitHub (Oct 22, 2025):
I ran into these same issues (I have ZFS backed storage but not proxmox). I think my instance is running well using the following steps.
Rollback to pre-10.11.0 install and stop the container.
Update to 10.11.0 and let the upgrade complete so the web interface loads.
Once loaded shutdown the updated Jellyfin container BEFORE letting a library scan run.
Change the database.xml to Opportunistic locking.
Start the container up again and run a full library scan.
This seems to have resulted in a running Jellyfin instance on 10.11.0
@papavictor commented on GitHub (Oct 22, 2025):
@Kitt3120 I had to disable my OpenSubtitles plugin, I originally thought it contributed to the issue, as I had hundreds of those entries in my log, too. On the last release, I believe after the 5 free downloads, the 6th attempt would give an error then the plugin would stop. But prior to that, this issue existed previously, where it would continue to attempt even if the results were failures.
I also left my full library scan running with Optimistic and a single parallel scan task overnight. It hasn't moved from 85% in over 20 hours, though I no longer have "database table locked" messages. I suspect this is just very slow at scanning music, as that's where most of my errors were previously, and I have > 100k songs.
edit:
Just noticed that none of my Android clients are able to load the UI, though my desktop works okay, and Kodi is still playing files. I restarted jellyfin, and my android clients are still unable to login.
@papavictor commented on GitHub (Oct 23, 2025):
@JPVenson I see issue group #15101 opened for this, but my filesystem is ext4, not zfs. I'm running a second full scan, and the behavior is the same, 20h at 85%. Will this be the case with every scheduled full library scan, or is this just part of the migration / db cleanup?
@papavictor commented on GitHub (Oct 23, 2025):
Looks like a new scan kicked off while the other one was running. Not sure if it finished independently, or there was a race condition that caused it to stop prematurely. It was still at 85% up to this point.
[2025-10-22 23:54:20.527 -04:00] [INF] "Scan Media Library" Completed after 1306 minute(s) and 46 seconds@felix920506 commented on GitHub (Oct 23, 2025):
@papavictor are you having those problems even after setting locking mode to pessimistic?
@teian commented on GitHub (Oct 23, 2025):
Getting the same issue when triggering a library scan
@papavictor commented on GitHub (Oct 23, 2025):
@felix920506 my most recent full library scan ran 21+ hours in Optimistic mode with 1 scan task, but I didn't get the database locked error message. Is pessimistic likely to do any better? I'll run it today and report back.
@felix920506 commented on GitHub (Oct 23, 2025):
Pessimistic will be slower but less likely to hit database locked errors
@Kitt3120 commented on GitHub (Oct 23, 2025):
Been a couple of days. Still using Optimistic and the low parallel scan task limit of 1. The initial, problematic library scan finished after >24 hours. Since then, Jellyfin has been working fine for me. Everything is as fast as it is supposed to be again. Another library scan ran 18 hours ago, and it finished in 4 minutes. That's a huge difference in duration. I can't reproduce the behaviour right now. I did not restart the container since then. It just works now and I don't want to break it again x)
@papavictor commented on GitHub (Oct 23, 2025):
After my first scan completed (or was interrupted?), my second scan with Pessimistic is still running, 9 hours as of this point. But I managed to get my android clients to login and load the UI by clearing the app cache.