Docker run override entrypoint with shell script which accepts arguments

It is because of the quotes you're using around your command.

When you run docker run --entrypoint "/usr/local/tomcat/entrypoint.sh -a param1 -b param2" tomcat:jre8 Docker treats whatever is within those quotes as a single script file.

As you can see from the error:

stat /usr/local/tomcat/entrypoint.sh -a param1 -b param2: 
no such file or directory\"\n".

It's trying to perform a stat on the file before running it, so it knows if it exists.

Place the arguments to your entrypoint at the end of your docker command like so:

docker run --entrypoint <entrypoint.sh> <image:tag> <arg1> <arg2> <arg3>

Your command becomes:

docker run --entrypoint /usr/local/tomcat/entrypoint.sh tomcat:jre8 -a param1 -b param2 

Have a look at the code snippets in the official documentation:

The ENTRYPOINT of an image is similar to a COMMAND because it specifies what executable to run when the container starts

https://docs.docker.com/engine/reference/run/#/entrypoint-default-command-to-execute-at-runtime

N.B: Answering this old question because the proposed answer are not satisfying me as they are partly wrong.

Short answer: There is no way to override the entrypoint with multiples arguments but you can move them to the command (part after the image name) that will work

---

More detailed answer:

After some testing and reading the docs it's obvious that there is no way to mimic the dockerfile or docker-compose entrypoint behavior with docker run.

The proposed answers are overriding the entrypoint to a single binary (i.e. without args) and putting the originals arguments to the COMMAND.

That is often doing the job but there is really a conceptual difference that you can reveal using docker inspect.

In docker, ENTRYPOINT is the binary + the default args that will be launched at startup and that are not supposed to be changed by the user at normal use. COMMAND are the remaining arguments or parameters that you want user to change (ex: the targeted hostname of ping).So they are conceptually different.

Saying that in many case this is not a matter to move args from entrypoint to command for a one time container the resulting command will look the same.

I think this is also worth noting:

If you have a bunch of arguments to your docker run command, your --entrypoint should come first.

I don't know which of my arguments was the problem, but putting --entrypoint "/bin/bash" at the end did not prevent execution of the ENTRYPOINT from the Dockerfile. My arguments included:

• 1x --rm
• 1x --name
• 1x -it
• 3x -v
• 6x -p
• 4x -e