Be very careful using this over Samba, even with WAL mode enabled. I corrupted an important testing DB this way. Thankfully .recover came to the rescue and only a small amount of data was lost (but the test team had to wait a couple hours for me to bring the test environment back online).
The WAL journal mode does not work over Samba. See the first disadvantage from https://www.sqlite.org/wal.html:
> All processes using a database must be on the same host computer; WAL does not work over a network filesystem. This is because WAL requires all processes to share a small amount of memory and processes on separate host machines obviously cannot share memory with each other.
The presence of the `-shm` file is one of the signs that the database is currently operating in WAL mode, and must only be accessed from the machine hosting the database file.
Looking at the list of journal modes supported (https://www.sqlite.org/pragma.html#pragma_journal_mode), you should see if the problem happens with the default `DELETE` journal mode.
Also, see https://www.sqlite.org/atomiccommit.html#_broken_locking_imp... for warnings about the SQLite that ships with macOS.
That is not the only limitation of WAL mode.
“It is not possible to change the page size after entering WAL mode.”
“In addition, WAL mode comes with the added complexity of checkpoint operations and additional files to store the WAL and the WAL index.”
https://www.vldb.org/pvldb/vol15/p3535-gaffney.pdf
“SQLite does not guarantee ACID consistency with ATTACH DATABASE in WAL mode. “Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is ":memory:" or if the journal_mode is WAL, then transactions continue to be atomic within each individual database file. But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not.”