Docker Community Forums

Share and learn in the Docker community.

Unable run open62541 with docker-compose but no problems running it with docker

Hello.

Im trying to start open62541 with docker-compose.
But I get the following error:

fatal/userland  Unable to load file /opt/open62541/pki/created/server_key.der.

the path /opt/open62541 does not exist on the host.
However when running it directly with docker, not docker-compose it works.
Why does this error occur? What do I miss?

Docker-compose.yml:

version: "3.9"
services:
  OPCUA:
    image: open62541/open62541
    user: "1000:1000"
    ports:
      - "4860:4840"

Docker run cmd:

sudo docker run -p 4840:4840 open62541/open62541

docker-compose version 1.29.2
Docker version 20.10.7

Link to the container: open62541/open62541 (docker.com)
Link to Dockerfile: open62541/docker (github.com)

Does anyone have experience with running an open62541-Server under Docker/docker-compose? Is it even advisable to do so?

Regards Arisys

ok i figured:
removing the user from the docker-compose.yml solves the issue.
as in:

version: "3.9"
services:
  OPCUA:
    image: open62541/open62541
    ports:
      - "4860:4840"

But this should be the default user for docker or not?
I usually have issues when acessing mounted volumes, without adding a user.
Again. What am I missing? How can i preserve the
user: "1000:1000"-line ?
Regards Arisys

1 Like

What do you mean by “default user for docker”? If it’s about the default user inside the container, then it pretty much depends on how the image is build. I am not aware of any world wide agreement amongst image maintainers to use a specific uid:gid for their non privleged users inside their image.

If the image seem to be ment to be run with a non privliged user, typicaly files are owned by this users uid/gid. Of course overriding the uid:gid can yield permission problems… which it does in case of this image.

Some images start as root (like the linuxserver images), change ownership of folders and perform other preparation tasks, then start the main process with restricted permissions.

And finally we have images that start as root and start the main process with priviliged permissions…

What you write is typicaly true for volume declaration that bind-mount a hots folder into a container folder.

1 Like

Ok I see. I had the misconception of it being a “special” Docker user. But it seems it is just the first user after root i.e. me. (foud out with cat /etc/passwd|grep 1000)

ok that seems to be the problem.
I will rebuild the container with different ownership and try again.

Thank you