Samba Share Database Locked [ `sqlite3.OperationalError: database is locked` ]

Hi. I set up a Samba share on my main computer so I could access my Gramps database from my laptop. Main computer is running Linux Mint 22.3 (Ubuntu 24.04). The Laptop is running Xubuntu (Ubuntu 24.04).

The Samba share is set up to share my home directory structure R/W with my username. Samba version is 4.19.5-Ubuntu.

On the laptop I’m running mount.cifs version 7.0. The line to mount is:

sudo mount -t cifs //xxx.xxx.xxx.xxx/user_name /home/username/samba_share --verbose -o username=username,uid=1000,gid=1000,dir_mode=0755,file_mode=0644

Where xxx.xxx.xxx.xxx is the correct IP address and user_name is my username. This connects successfully, and the ownership and permissions look correct.

Main Computer:

$ ls -lat .var/app/org.gramps_project.Gramps/data/gramps/grampsdb/69b95380
total 6088
drwxr-xr-x 2 user_name user_name 4096 Mar 23 16:57 .
-rw-r–r-- 1 user_name user_name 0 Mar 23 16:57 meta_data.db
-rw-r–r-- 1 user_name user_name 6217728 Mar 23 09:08 sqlite.db
-rw-r–r-- 1 user_name user_name 29 Mar 17 09:33 name.txt
-rw-r–r-- 1 user_name user_name 6 Mar 17 09:13 database.txt
drwxr-xr-x 3 user_name user_name 4096 Mar 17 09:13 ..

Laptop:

$ ls -lat samba_share/.var/app/org.gramps_project.Gramps/data/gramps/grampsdb/69b95380/
total 6080
drwxr-xr-x 2 user_name user_name 0 Mar 23 16:57 .
-rw-r–r-- 1 user_name user_name 0 Mar 23 16:57 meta_data.db
-rw-r–r-- 1 user_name user_name 6217728 Mar 23 09:08 sqlite.db
-rw-r–r-- 1 user_name user_name 29 Mar 17 09:33 name.txt
-rw-r–r-- 1 user_name user_name 6 Mar 17 09:13 database.txt
drwxr-xr-x 2 user_name user_name 0 Mar 17 09:13 ..

Having closed the database prior to exiting Gramps on the main computer, I can open the database with no issues with Gramps on the laptop. Gramps version 6.07. The preferences for both installation of Gramps is identical except that Database path is /home/user_name/.var/app/org.gramps_project.Gramps/data/gramps/grampsdb on the main computer, and /home/user_name/samba_share.var/app/org.gramps_project.Gramps/data/gramps/grampsdb on the laptop. The Backup path is similarly modified.

The database is fully visible, and does not show the lock symbol before I load it, but if I try and add any data I get the following error:

43796: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
File “/app/lib/python3.13/site-packages/gramps/gui/editors/editeventref.py”, line 328, in ok_clicked
with DbTxn(_(“Add Event”), self.db) as trans:
~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/lib/python3.13/site-packages/gramps/gen/db/txn.py”, line 82, in exit
self.db.transaction_commit(self)
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File “/app/lib/python3.13/site-packages/gramps/plugins/db/dbapi/dbapi.py”, line 331, in transaction_commit
self.dbapi.commit()
~~~~~~~~~~~~~~~~~^^
File “/app/lib/python3.13/site-packages/gramps/plugins/db/dbapi/sqlite.py”, line 167, in commit
self.__connection.commit()
~~~~~~~~~~~~~~~~~~~~~~~~^^
sqlite3.OperationalError: database is locked

I’m rather stumped at this point. Any help would be appreciated. Thanks.

Claude, my AI friend says:

This is a classic SQLite-over-CIFS locking problem. SQLite uses byte-range locking (BRL) to manage write access, and CIFS/Samba’s
implementation of BRL conflicts with SQLite’s expectations, causing the “database is locked” error even when no other process has the
file open.

Fix: Add nobrl to your mount options

sudo mount -t cifs //xxx.xxx.xxx.xxx/user_name /home/username/samba_share --verbose \
-o username=username,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,nobrl

The nobrl option disables byte-range locking on the client side, which lets SQLite fall back to its own locking mechanism. This is the
standard fix for SQLite on CIFS mounts.

You can also add cache=none if you see stale data issues:

-o username=username,uid=1000,gid=1000,dir_mode=0755,file_mode=0644,nobrl,cache=none

Important caveat

Running a live SQLite database over a network share is inherently risky — even with nobrl, network interruptions or latency can cause corruption. For a Gramps genealogy database you care about, I’d strongly recommend:

  • Never have both computers open the database simultaneously
  • Keep regular backups (Gramps has a built-in backup feature under Family Trees → Export)
  • Consider using Syncthing or rsync to sync the database file between machines instead of accessing it live over the network — safer and faster

The nobrl fix will almost certainly resolve your immediate error, but treat the network share as a convenience, not a reliable multi-access solution.

@dsblank Many Thanks! Gene

1 Like