(Edited to be OS-agnostic, as Keith's following comment shows this should have been.) We are told, if not directly at least by inference, that the OP's problem manifests within a single process. He uses the phrases "a thread" (contrast with "the thread"), "application", "per-thread", "different thread" and "threads", which together, on Windows or Unixen, implies that the threads are running within a single process, (because "process" and "running application" are normally used interchangeably for user-level programs, particularly those created by newer programmers.) We are not told what the programming language is, or the execution environment beyond use of Docker. At Docker doc "[Images and containers](https://docs.docker.com/get-started/)", we can see that "Fundamentally, a container is nothing but a running process, with some added encapsulation features applied to it in order to keep it isolated from the host and from other containers. One of the most important aspects of container isolation is that each container interacts with its own private filesystem; this filesystem is provided by a Docker image." Hence, there would be no chance of the same DB file being accessed by multiple, independently running Docker processes. (And if the OP was so silly as to attempt to use the **same** DB file from more than one Docker process, his strategy of having all but one sqlite3_open call blocked from creating the DB file would have soon failed much less mysteriously, I surmise.) Given that the execution environment is a single (Docker) process, any UAC intervention (if on Windows, in the form of protected directory faking) should still reach the same file when the same path is provided (as the OP claims is done.) Of course, as conjectured earlier in this thread, Docker could be doing almost any random thing when the OS file I/O API's are munged to redirect to the Docker per-process isolated file system. That possibility is good reason to become very sure that, in fact, the exact same file path is passed into sqlite3_open_\*() for every call intended to reach the same DB file. If that were conclusively established, it would be time to closely investigate what (in Tarnation) Docker's simulacrum of the OS file I/O API is actually doing. There are tools, premature to recommend now, which could be used to convict Docker of extreme chicanery if it cannot access the same file reached via different (munged) file open API calls with the same filename parameter. However, until such chicanery is carefully pinned upon Docker, I think it is premature to begin investigating why the containerizing tool would do such a thing, and do it inconsistently within the same running Docker image. After all, a great many applications, (including the OP's problematic one at times), manage to use the (faked) OS file I/O API without such goofiness. Now, with that all said, it would be interesting to discover what the OP's application does when not run in the Docker environment. This is not a good substitute for traditional debugging and problem narrowing, but it could eliminate a mess of conjectural possibilities. (I do not claim to be a Docker expert.)