Syntax accessing windows file names from linux

I know this is an off topic, so please excuse me, but the docker forum seems not to be able to help me since I cannot post more than 2 topics as a new user and I don't know howto delet the two I have entered.

I am using windows 11 on my main system, and I want to have node-red installed on Docker, which works with no problems. Problem occurs when I try to access windows file names from Docker, or in this case, the name of a database in the Sqlite container, since I have no ideas about the syntax. I have tried the windows file name using quotes, double quotes, doble and single slashes, plain text, but nothing seems to work, and of course same problem from the sqlite node when entering the database name, since I don't know what the name in the Sqlite container would look like from Node Red where the database name is /home/project/sqlite-db/db-main.sqlite
Best regards

Ulf H.

Docker is a "container" - a sandbox, from which you cannot break out, it does not have access to the local filesystem unless you have told the container during creation to be able to access certain paths, this can be done using bind mounts where you "mount" the local directory inside to container on an arbitrary location.


/home/project/sqlite-db/ (local directory) > /mnt (inside the container)

can be done using the option:

-v /home/project/sqlite-db/:/mnt

when creating the container.

Then from node-red (running inside the container) you can access the database on /mnt/db-main.sqlite

1 Like

re Windows file paths and names, you can use the same as Linux since Windows supports forward-slashes as well as back-slashes. The only real difference (other than the layout of a Windows filing system of course) is that the root of a Windows FS starts with a drive letter and colon.

Thank you so much! It's all in the concept - need to find a good technical documentation on docker.
I have tried several sqlite containers, and the one I am using now keinos/sqlite3 lets me create a database where the database file is stored local on my computer. Running docker -v d:/sqlite/test.db/:/mnt does not give any error messages, thoug I have no ideas about how to check it. When I try to mount the database as shown in your example, but node red, which is running in the nodered/node-red image does not accept the syntax /mnt/db-main.sqlite. I have checked that the database exsist using docker run --rm -it -v d:/sqlite:/db some-sqlite test.db

Best regards

Ulf H.

Thank you - I am starting to understand the file syntax. One of my problem was (and maybe still is) that I have problems getting what is local and what is inside the container.

Best regards

Ulf H.

I feel your pain. Docker can be a bit of a pain to use if you don't use it all the time. I don't and I still don't pretend to understand more than the very basics.

However, one thing I did remember is that you can get to a command line inside your container. Can't remember how I'm afraid but I remember that you can. That being the case, you can check out how things look from inside the container and that should help a lot.

1 Like

Try -v d:/sqlite/:/mnt instead. In node-red it should become /mnt/test.db. You mount directories with -v (as -v means "volume".)

1 Like

I recon there is something (in face quite a lot!) I dont understand.
The image I use this Dockerfile:
FROM alpine:3.10
RUN apk add --update sqlite
RUN mkdir /db

ENTRYPOINT ["sqlite3"]
CMD ["test.db"]

I can then access the image using
docker build -t database .
I can now access the database using
docker run --rm -it -v d:/sqlite:/db database test.db
But I still don't get access to the database from node red.

failed to open d:/sqlite:/db/test.db

Lets start at the beginning: Why do you create/build a docker container that only contains sqlite ?
Please refer back to my first response. Sandboxes are sandboxes. Node-red will not be able to access a file that lives in another container.

My assumption was that your sqlite file lives in your local file system.

If I understand this correct, the sql data file lives on the local file system - I can use a dir command and find it on the on the directory where I created the image. I can also change the Dockerfile and use a subdirectory (but it must first be created from Windows) and then I will find the database file there.

I will have to look at your sugestion, but I recon I should do some more reading first. I have a tendency to do cut-and-try, sorry about that

Best regards

Ulf H,

But why use a "Dockerfile" in the first place ? You can install sqlite on windows ? You could even install it via the palette manager inside node-red itself (not when running node-red in a container however). You see, docker is not the solution for all the problems in the world. I would recommend to run node-red without docker and all problems suddenly clear up.

I think that is a good solution. Have done this several times - just wanted to learn Docker

I guess the point really is understanding the difference between what is needed to access a SQLite db and the data that defines the db.

One thing that might be useful would be to define a pre-configured Node-RED with nodes installed to support SQLite and any other tools you need in a single container. That container can then be used anywhere that supports standard containers (Azure/AWS for example or multiple local devices). Then have a separate container for all the data needed - which is what the Node-RED standard container does with its data container. That then is also portable/distributable.

So containers are useful where you need to either be able to horizontally scale (multiple copies of identical service), recreate/distribute identical copies to many locations or where a service configuration is so horrid you only really want to have to ever think about it once (better still, get someone else to think about it and set it up)!

So I'll always choose to run my Ubiquiti Wi-Fi controller in a container because the setup is horrid needing several components including the dreaded Java and MongoDB. But not so, Node-RED which is a simple install on my single server (and a simple install on my dev desktop).

1 Like

That is a good point!