Are you saying you get that error when trying to pack the database?  That operation requires exclusive access by the connection performing the pack, so all other connections must first be closed, and no new connections will be possible until the pack has completed and the exclusive connection is closed.  Or are you getting the Lock timeout error during normal operations when not trying to perform a pack on the database?

Some further questions so we can better understand your usage in order to advise you:

Do you use connection pooling?

Do you use transactions?

Is the database file being accessed over a network share?

So, those typical issues can all be ruled out. We've exchanged a bit more information on a support ticket, so for anyone else checking this thread who gets a similar error:

This was happening while a new RAID configuration was building on the server which would cause HDD access to be slower than normal. Now that the building has completed it seems to be working normally again, from what I understand. Of course, that isn't the only scenario which could cause lock timeout errors, but it is a caveat to keep in mind when planning RAID configuration changes.

From the error message and stack trace we can tell that the lock timeout error was thrown when attempting to open the database and further that it was attempting to open data storage named by the full filename (as opposed to a table name). The full file name is used as the name when the data storage being accessed is the main [database schema] table. When the engine opens a database it must read this table to initialize a few things, so an inability to access the main [database schema] table for too long continuously could result in such lock timeout errors in attempting to open the database. This could be caused by a separate connection performing a modification to the [database schema] table or otherwise holding a lock preventing reading by other connections.

By some subsequent experimentation and then double-checking MDSN documentation we discovered that the file-locking API used by VistaDB in this scenario is actually exclusive rather than allowing overlapping reads--even when the database has been opened in NonExclusiveReadOnly mode--at least with .NET 4 (and 4.5). We're investigating whether this file-locking behavior changed in the underlying framework or OS at some point or was intended as an exclusive lock (which is safe, but more contentious than necessary for a read-only query) in the way VistaDB uses that API.

Note that the SharedReadOnly mode prevents any overlap with *ReadWrite modes (or any other write-access file opens) and thus avoids the need for any locking and allows any number of other SharedReadOnly connections to overlap without contention.  This mode can be useful if a lot of overlapping read-only access is needed with little or no use of write access.  (The Exclusive* modes also avoid the need for further locking but, of course, can't overlap with any other connections, anyway.)