Base Images & Volume & mkdir

[coderlol]

If the base image Dockerfile has a VOUME /var/lib directive, then an image derived from the base image cannot do a RUN mkdir -p /var/lib/somedir

The mkdir command has no effect. I think it is convenient to have the base image export a VOLUME and the derived images can create their own structure without having to explicitly calling their own VOLUME.

As-is, the base image must not issue the VOLUME /var/lib or the derived images won't be able to create a directory in /var/lib

[crosbymichael]

I'm not sure I understand what the expected behavior should be, can you give an example dockerfile to reproduce?

[fdemmer]

i've run into this too and here's an example:

first Dockerfile:

FROM ubuntu:latest
VOLUME /etc

this Dockerfile is then used to build image "base":

# docker build -t base .
Uploading context  2.56 kB
Uploading context 
Step 0 : FROM ubuntu:latest
 ---> c0fe63f9a4c1
Step 1 : VOLUME /etc
 ---> Running in 8957e1485c31
 ---> 17879464e604
Successfully built 17879464e604
Removing intermediate container 8957e1485c31

... looks good, works.

second Dockerfile, should add more config and create a directory for later use in /etc:

FROM base
RUN mkdir /etc/ssl
ADD nginx.conf /etc/nginx/nginx.conf

again we build:

# docker build -t nginx .
Uploading context 3.072 kB
Uploading context 
Step 0 : FROM base
 ---> 17879464e604
Step 1 : RUN mkdir /etc/ssl
 ---> Running in ef0693690e0f
 ---> d94dba1a25f4
Step 2 : ADD nginx.conf /etc/nginx/nginx.conf
 ---> d4debccd60b9
Successfully built d4debccd60b9
Removing intermediate container ef0693690e0f
Removing intermediate container 3da3c324ab95

... looks good, but did not work:

# docker run -i -t nginx  bash
root@e158ee019e16:/# ls -la /etc/ssl
ls: cannot access /etc/ssl: No such file or directory
root@e158ee019e16:/# ls -la /etc/nginx/
total 8
drwxr-xr-x  2 root root 4096 Apr 22 21:11 .
drwxr-xr-x 57 root root 4096 Apr 22 21:12 ..
-rw-r--r--  1 root root    0 Apr 22 21:10 nginx.conf

as you see above, the ADD command worked (my sample nginx.conf is really empty, that's ok), but the RUN command to create the "ssl" directory was executed during the build (it seems), but then it is missing from the container when run.

edit: same problem with RUN rm. i was trying to remove the sites-enabled/default and use ADD my own site.conf, but default always remained. overwriting default with ADD works, but is not a very nice solution.

[fdemmer]

so I ran into this again with a different scenario just now and it's making me doubt if i am using VOLUME and Dockerfiles right at all...

• i created a base image, that just installs openldap on top of an ubuntu image. in that dockerfile i set VOLUME /var/lib/ldap to have the database outside of the container root-fs.
• i then use this base image with FROM in another dockerfile to add some custom config (as recommended in method 2 here: #2022 (comment)). the custom config is set via -e parameters on run and applied inside using dpkg-reconfigure, which modifies the database (on the volume).

that causes all kinds of weird behaviour of the ldap server. eg. the domain reconfiguration is applied, but other default objects are not there in the new base dn. anyway, point is: as soon as i remove the VOLUME for the database path from my base image, everything works as expected.

volumes really sound great the way the docs and articles like this http://crosbymichael.com/advanced-docker-volumes.html describe them, but if i cannot modify their contents when "inheriting" them FROM other images, how is the "base image+config image"-pattern supposed to work?

[LK4D4]

+1 on this issue, I think this is clearly a bug

[e-max]

I've made simplest example to demonstrate this issue:

Parent image - create file

[e-max@e-max docker]$ cat ./parent/Dockerfile 
FROM ubuntu
RUN mkdir /tmp/docker/
RUN echo "hello" > /tmp/docker/hello
VOLUME ["/tmp/docker/"]

Child image - remove file

[e-max@e-max docker]$ cat ./child/Dockerfile 
FROM parent
RUN rm /tmp/docker/hello

Build

[e-max@e-max docker]$ docker build -t parent ./parent/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu
 ---> 5cf8fd909c6c
Step 1 : RUN mkdir /tmp/docker/
 ---> Using cache
 ---> 0925b684892f
Step 2 : RUN echo "hello" > /tmp/docker/hello
 ---> Using cache
 ---> c63b75c84ecc
Step 3 : VOLUME ["/tmp/docker/"]
 ---> Using cache
 ---> 71a00868d3a2
Successfully built 71a00868d3a2
[e-max@e-max docker]$ docker build -t child ./child/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM parent
 ---> 71a00868d3a2
Step 1 : RUN rm /tmp/docker/hello
 ---> Using cache
 ---> dcde5cf04e6b
Successfully built dcde5cf04e6b

And test - file still exist in child image.

[e-max@e-max docker]$ docker run -i -t --rm child cat /tmp/docker/hello
hello
[e-max@e-max docker]$

[tiborvass]

@e-max Thanks. I could reproduce with master.

[LK4D4]

Okay, I did little research and it seems that volume is non-mutable between Dockerfile instruction.
Here even smaller Dockerfile for testing:

FROM busybox

RUN mkdir /tmp/volume
RUN echo "hello" > /tmp/volume/hello
VOLUME ["/tmp/volume/"]
RUN [[ -f /tmp/volume/hello ]]
RUN rm /tmp/volume/hello
RUN [[ ! -e /tmp/volume/hello ]]

On each instruction we create new volume and copy content from original volume.

[jessfraz]

@cpuguy83 is this fixed?

[cpuguy83]

@jfrazelle No, see #7133

[jessfraz]

ah ok bummmeerrrrr

[tomfotherby]

I just ran into this issue. I was trying to extend from the official mongodb image from the hub and seed the database with my apps skeleton data, but because the parent container uses VOLUME /data/db, any mongo data I add in my extended container doesn't persist the build. Shame 😞 .

( I blogged about my workaround)

[pmoust]

Relates #8647

[sirlatrom]

@gotgenes It doesn't look like jhister is an official image.

[Neirda24]

+1 for this feature

[Wilfred]

Would it be feasible to error or at least warn in this situation? Silently failing is unfortunate.

[pjweisberg]

I've been relying on the behavior described in #21728 for several months; I had no idea it was a bug until helped a colleague figure out why the data he was putting in /var/lib/mysql was getting discarded. He spent hours trying to figure out what was blowing away his data.

He might end up having to just copy mysql's Dockerfile into his own instead of basing his image on theirs. Maybe I'm supposed to do the same, in case #21728 ever gets "fixed".

At minimum, child Dockerfiles should have a way to un-VOLUME a directory that was declared as a VOLUME by the parent. At least long enough to modify its contents.

[thaJeztah]

@pjweisberg see #3465 for that topic 👍

[dominikzalewski]

So this issue is like what... 5 years old... just lost 2h 45m trying to figure out what's wrong. Is it ever going to be fixed?

[cpuguy83]

Use DOCKER_BUILDKIT=1
The new builder does not exhibit this behavior.

[dominikzalewski]

Thank you very much for your answer/hint. This resolves all of my issues! As you can see below, the default behavior does not work, and the one you proposed does:

That's a very simple Dockerfile that I'm using:

FROM wordpress:latest
ARG UPLOAD_DIR=/var/www/html/wp-content/uploads

RUN mkdir -p $UPLOAD_DIR
RUN ls -lhd $UPLOAD_DIR

I wish this was standing out from the documentation more. I'm developing for quite a while using docker and only now I started using this: https://docs.docker.com/develop/develop-images/build_enhancements/

Perhaps it's better if this 'new' builder was the default?

[thaJeztah]

I wish this was standing out from the documentation more

I thought we had a note in the documentation about this behaviour, but perhaps it got lost during a rewrite (can't find it in a quick search https://docs.docker.com/engine/reference/builder/)

Perhaps it's better if this 'new' builder was the default?

That's definitely the goal 👍