By using the same image for both the data-container, docker was able to seed the
volume with the data from the image when we created the data container. Data
from the image is only ever seeded into a volume when the volume is created.
Since busybox was originally used as the image for the data-only container,
and there is no /foo in the busybox image, docker created the dir as root
and nothing else. Since --volumes-from does not actually create a volume, it
just re-uses an existing volume, nothing ever made it into the volume itself.
Since the volume dir was owned by root and we were trying to use a non-root user
in the container to modify the volume, it failed.
This is extremely common with images like mongodb, mysql, and postgres.

So are we stuck using the same image for both? Well, yes if you want it to work
as expected... however stuck isn't really the correct term here. The reason
we are using a minimal image is to save space, but this is not what actually
happened...

The debian:jessie image is roughly 150MB. Because of the way Docker works, we
can re-use the debian:jessie image 1000 (or 10000, or 100000) times and it is
still only ever using 150MB.
A container itself does not take up any space unless as part of running it you've
written something to disk. This is because a container's filesystem is
essentially a write-layer over the image. This enable Docker to use an image
N times (for containers) without taking up any extra space.
So in reality, by using busybox, we've actually taken up more space than
by using the same image (ie, mickey_foo in the example) multiple times.

In the above example, the command the data-only container ends up running is
/bin/sh -c '/bin/echo Data-only container for mydb'.
This makes the data-only container relatively easy to grep for, and also gives a
good clue, based on the command being run in the container, what the container
is actually for.