Permission denied to execute entry point in Docker

[hseeberger]

Building a Docker image for https://github.com/hseeberger/echo-httpd works like a charm, but running a Docker container from it fails:

docker$ docker run echo-httpd:1.0.0
bash: bin/echo-httpd: Permission denied

[muuki88]

Hi Heiko,
I couldn't find anything suspicious in your config. I won't have a PC this week to check your build myself,
so could you post the generated dockerfile here?

Just run. docker:stage and under target/docker you should find it.

[fiadliel]

I tried building your project, and I couldn't access your base image, hseeberger/java. Using the default image (dockerfile/java), it worked fine for me.

Also, try running this command:

$ docker run --entrypoint /bin/bash echo-httpd:1.0.0 -c "ls -l /opt/docker/bin; id"
total 20
-rwxr--r-- 1 daemon root 11742 Aug 25 2014 echo-httpd
-rw-r--r-- 1 daemon root 6170 Aug 25 2014 echo-httpd.bat
uid=1(daemon) gid=1(daemon) groups=1(daemon)

Here echo-httpd is executable by user "daemon", and the default user is "daemon", so it should be possible to run the script.

[hseeberger]

@muuki88, my Dockerfile:

FROM dockerfile/java
MAINTAINER Heiko Seeberger <[email protected]>
EXPOSE 8080
ADD files /
WORKDIR /opt/docker
RUN ["chown", "-R", "daemon", "."]
USER daemon
ENTRYPOINT ["bin/echo-httpd"]
CMD []

@fiadliel, I'm glad it's working for you which means I'm hopefully not far from getting it working. Yet, even after changing the base image do dockerfile/java I still have the same issue.

Executing the command you suggested results in:

echo-httpd$ docker run --name test --entrypoint /bin/bash echo-httpd:1.0.0 -c "ls -l /opt/docker/bin; id"
ls: cannot access /opt/docker/bin: Permission denied
uid=1(daemon) gid=1(daemon) groups=1(daemon)

BTW, I'm on Mac OS 10.9.4, using boot2docker 1.2:

echo-httpd$ boot2docker version
Client version: v1.2.0
Git commit: 22b11f1
echo-httpd$
echo-httpd$ docker version
Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): darwin/amd64
Server version: 1.2.0
Server API version: 1.14
Go version (server): go1.3.1
Git commit (server): fa7b24f

Do you guys know whether "Client API version: 1.14" and "Server API version: 1.14" might be an issue?

[fiadliel]

Also ls -l /opt/docker? (or parent directories until you don't get a permission denied error).

I updated to boot2docker 1.2 and rebuilt, still cannot reproduce. I wonder if it's due to moby/moby#6047

Also, can you try setting daemonUser in Docker := "root" - to see if the permissions issue goes away then? (Note, I would prefer for programs not to run as root unless it's required).

[hseeberger]

Gosh!

echo-httpd$ docker run --name test --entrypoint /bin/bash echo-httpd:1.0.0 -c "ls -l /; id"
total 68
drwxr-xr-x   2 root root 4096 May 19 14:56 bin
drwxr-xr-x   2 root root 4096 Apr 10 22:12 boot
drwxr-xr-x   2 root root 4096 Aug 25 15:45 data
drwxr-xr-x   4 root root  340 Aug 25 15:45 dev
drwxr-xr-x 107 root root 4096 Aug 25 15:45 etc
drwxr-xr-x   2 root root 4096 Apr 10 22:12 home
drwxr-xr-x  15 root root 4096 May 19 14:56 lib
drwxr-xr-x   2 root root 4096 Apr 16 20:35 lib64
drwxr-xr-x   2 root root 4096 Apr 16 20:35 media
drwxr-xr-x   2 root root 4096 Apr 10 22:12 mnt
drwx------   4 root root 4096 Aug 25 13:48 opt
dr-xr-xr-x 194 root root    0 Aug 25 15:45 proc
drwx------   3 root root 4096 May 19 14:57 root
drwxr-xr-x   8 root root 4096 May 19 14:57 run
drwxr-xr-x   2 root root 4096 May 19 14:56 sbin
drwxr-xr-x   2 root root 4096 Apr 16 20:35 srv
dr-xr-xr-x  13 root root    0 Aug 25 15:45 sys
drwxrwxrwt   2 root root 4096 May 19 15:27 tmp
drwxr-xr-x  22 root root 4096 Aug 25 13:46 usr
drwxr-xr-x  20 root root 4096 Aug 25 13:48 var
uid=1(daemon) gid=1(daemon) groups=1(daemon)

Why on earth is /opt 700?

[fiadliel]

Very strange.

So, when you build the image, you should see a log like:

[info] Step 0 : FROM dockerfile/java
[info]  ---> f9793c257930
[info] Step 1 : MAINTAINER Heiko Seeberger <[email protected]>
[info]  ---> Using cache
[info]  ---> f6e69fcd84ad
[info] Step 2 : EXPOSE 8080
[info]  ---> Using cache
[info]  ---> c7b382552f58
[info] Step 3 : ADD files /
[info]  ---> 726699aced8e
[info] Removing intermediate container 2e69309b7033

Can you identify the hash (e.g.) f9793c257930 where the 700 perms initially appear?
For example, docker run --entrypoint /bin/bash f9793c257930 -c "ls -l /"

[hseeberger]

Great idea!

It's this little sucker:

[info] Step 3 : ADD files /
[info]  ---> dffb03c73969
[info] Removing intermediate container 81e09ba08ead

[fiadliel]

Ah, interesting. What are the permissions of target/docker/files/opt?
How about the output of umask? This seems possibly consistent with a umask of 077... which would remove group and other permissions...

[hseeberger]

Woot, you just answered the 1 million lira (former Italian currency) question!

Now I know how I can work around this, but I think native packager should allow users to be paranoid.

[fiadliel]

Agreed, this should be fixed, but the correct fix isn't 100% obvious to me. Stay tuned...

[muuki88]

Any progress on this?

[dublado]

I just set chmod permission +x to that entrypoint file before the build and everything run as i want at the container...

[cristhiano]

Same thing as @dublado here!

[alari]

it's a repeating problem of +x'ing the executable from sbt packager.
but -- deamon really does not own files after build
is any fix for this issue planned?

[leozilla]

I just ran into the same problem, as I am no Dockerfile expert, could somebody show me how to fix/work around this pls