> 3.7 is the version our sysadmins installed Why are you limited to only what your sysadmins installed? SQLite is easy to compile and install. You don't need complex packaging systems with carefully-crafted permission sets to make it work properly. It's a single executable. On some systems, you can even link it statically so it doesn't depend on platform libraries, so you may even be able to build on a different Linux system type and copy the executable over. > Which version of sqlite properly allows for read only access as i've described? Search for "read" in [the SQLite change log](https://sqlite.org/changes.html), then ask yourself if you're seriously wanting someone to bisect 8 years of history with numerous changes to the required functionality for you, without even having a reproducible test case to do the bisecting with. "linux OS" covers [hundreds](https://distrowatch.com/dwres.php?resource=popularity) of distributions, each of which supports many filesystems, atop which you have SQLite's own [multifarious build details](https://www.sqlite.org/howtocompile.html), creating a combinatorial explosion of likely sources for your problem. Would you like us to simply *guess* which one covers your particular case? What I can tell you without knowing your platform details is that the `--readonly` flag went into the `sqlite3` shell [in February of 2018](https://sqlite.org/src/info/06870bb15656b50b), subsequently released in 3.23.0. That feature alone might make the difference between success and failure. (The commit comment only speaks of the shell's `.open` command, but the flag is available to the shell itself, so you can add `--readonly` to your calls to `sqlite3` without using `.open` directly.) Another platform-independent guess is that you're using WAL mode, so the read-only WAL feature that went into 3.22.0 is what you need, possibly coupled with the `--readonly` flag. If these informed guesses are wrong, then we're down to filesystem issues, kernel details, build details...all things that are currently hidden from us by your vague "linux OS" specifier. I would not use the versions above to tell your sysadmins to install 3.22.0 or 3.23.0, though. I repeat my initial request: install the latest release, then let us know if that fails.