`unable to open database file` in DynamoDB image

[wrobelda]

I am getting the following after starting the DynamoDB container.

Initializing DynamoDB Local with the following configuration:
Port:	8000
InMemory:	false
Version:	2.6.1
DbPath:	/db
SharedDb:	true
shouldDelayTransientStatuses:	false
CorsParams:	null

Jul 03, 2025 4:08:42 PM com.almworks.sqlite4java.Internal log
WARNING: [sqlite] cannot open DB[1]: com.almworks.sqlite4java.SQLiteException: [14] unable to open database file
Jul 03, 2025 4:08:42 PM com.almworks.sqlite4java.Internal log
SEVERE: [sqlite] SQLiteQueue[shared-local-instance.db]: error running job queue
com.almworks.sqlite4java.SQLiteException: [14] unable to open database file
	at com.almworks.sqlite4java.SQLiteConnection.open0(SQLiteConnection.java:1480)
	at com.almworks.sqlite4java.SQLiteConnection.open(SQLiteConnection.java:282)
	at com.almworks.sqlite4java.SQLiteConnection.open(SQLiteConnection.java:293)
	at com.almworks.sqlite4java.SQLiteQueue.openConnection(SQLiteQueue.java:464)
	at com.almworks.sqlite4java.SQLiteQueue.queueFunction(SQLiteQueue.java:641)
	at com.almworks.sqlite4java.SQLiteQueue.runQueue(SQLiteQueue.java:623)
	at com.almworks.sqlite4java.SQLiteQueue.access$000(SQLiteQueue.java:77)
	at com.almworks.sqlite4java.SQLiteQueue$1.run(SQLiteQueue.java:205)
	at java.base/java.lang.Thread.run(Thread.java:840)

The /db folder is empty inside the container. This might be related to the fact I am using podman in place of docker.

[wrobelda]

Ah, this is because I had added a volume to docker-compose that would map to /db inside the container, in order to persist the database file, but I see that very file is initiated in dynamo.Dockerfile, which is somewhat unfortunate.

I believe this goes against the containerization paradigm, i.e. the image itself should be ephemeral and not modified at the runtime — meanwhile any synchronization continues to modify that image.

Moreover, each time docker-compose down is issued, the containers get nuked, which means that upon recreating them, all the browsers need to be reinitialized again.

The solution here is to make shared-local-instance.db initialization and its successful storage in \db happen at the time the container is being started in entrypoint.sh script. The \db with its shared-local-instance.db artifact, consequently, should also be mounted as a volume.

[wrobelda]

I'll create a PR later today which should fix this

[NicholasFlamy]

I believe this goes against the containerization paradigm, i.e. the image itself should be ephemeral and not modified at the runtime — meanwhile any synchronization continues to modify that image.

It does.

Moreover, each time docker-compose down is issued, the containers get nuked, which means that upon recreating them, all the browsers need to be reinitialized again.

Yep, it was designed for no down time AWS. This was never meant to be self hosted. They just point at the docker compose to make it seem like they care but most users aren't going to self host so they don't actually care.

I'll have to grab your PR's commits for my autobuild fork. Thanks for the work!