Sqlite Container initialisation with existing DB

[josefhuberfhcp]

Hi, i'am trying to set up a new wiki for my company using sqlite as the database type.
I am having troubles using the environmental variable DB_FILEPATH when creating the container with the following command:
docker run -d -p 8000:3000 --name MyWiki--restart unless-stopped -e "DB_TYPE=sqlite" -e "DB_FILEPATH =/DB.sqlite" requarks/wiki:2.4

After finishing the setup the database is located in the container in the \wiki\ folder with a name of "undefined" without the .sqlite extension. This is mirrored in the "Systems info" in the administrative area:

How do i use DB_FILEPATH variable correctly in order to reflect the path/name i specified (DB.sqlite)? (My current workaround: in the container edit the config.yml and change storage: $(DB_FILEPATH) to storage: DB.sqlite and rename the file "undefined" to "DB.sqlite", seems to work and "System Info" prints the right file name.

Secondly, i would like to backup the sqlite file and restore it in a new container. Therefore i copied the sqlite file from container1 to my local file system, set up container2 with the same settings and copied the file into container2, overwriting the newly created db and restarted container2. Unfortunately this seems to break container2:

I do not understand the nature of the migration lock error, when i open the sqlite file there is a migrations_lock table but the value ist set to zero.

What would be the right way to backup and redeploy a sqlite database in a new container?

It's my first time working with a wiki and also docker, any input would be much appreciated. Thank you.

Host Info
OS: [Windows 10 Home, Docker]
Wiki.js version: [2.4.107]

[winkelement]

This works for me (beware of whitespace in your example):

docker run -d -p 8080:3000 --name wiki-sqlite-test --restart unless-stopped -e "DB_TYPE=sqlite" -e "DB_FILEPATH=storage.sqlite" -v /Users/myname/dev/wiki-sqlite-test/storage.sqlite:/wiki/storage.sqlite requarks/wiki:2

This maps your .sqlite file to a folder in your local filesystem.

Check out https://docs.docker.com/storage/bind-mounts/

[josefhuberfhcp]

@winkelement Thanks a lot for the hint with the whitespace! I am used from programming that whitespaces don't make any difference, apparently they do. Now the creation of the new database with the environmental variable works.

I also found the reason for the migration lock error when copying an existing database to the container. While on windows the database file is writeable, it becomes non-writable when copying to the linux container because it was created in another container. I was not aware of this because i never worked with linux before. Setting the file permissions to write with chmod in the container made it work.

I also tried your approach with mounting the file from the local file system, it works as well. I only have a question concerning security: When deploying in a production environment, is it better to copy the db file to the container and have it protected from unwanted access, or is mounting from the local file system equaly save?

[winkelement]

[...] I only have a question concerning security: When deploying in a production environment, is it better to copy the db file to the container and have it protected from unwanted access, or is mounting from the local file system equaly save?

I am in no way qualified for an reliable answer to that but in general i would not recommend using sqlite for a production environment.
I may be totally wrong but from my understanding i don't see a big difference security wise. If an attacker has access to the server he can access files inside a container or outside with the same effort.