Writing issue with Docker beta on Mac & mounted volume from Dropbox

Docker Desktop for Mac
1

Expected behavior

Using a host mounted docker volume should provide a working filesystem

Actual behavior

It seems that under certain circumstances, processes in the container cannot write to the volume

Information

Docker version 1.12.0-rc3, build 91e29e8, experimental

Docker Mac Version 1.12.0-rc3-beta18 (build: 9996)
ec40b14c72adc0bff3b01fa8886dae7f2eee1541

Steps to reproduce the behavior

In a directory cloned from https://github.com/edasque/qmk_firmware

after running

docker build -t qmk .

then running the container like so:

docker run -t -i -v /Users/edasque/Dropbox/projects/qmk_firmware:/QMK:rw qmk make

the output is:

avr-gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

WARNING:
 Some git sub-modules are out of date or modified, please consider runnning:
 git submodule sync --recursive
 git submodule update --init --recursive

 You can ignore this warning if you are not compiling any ChibiOS keyboards,
 or if you have modified the ChibiOS libraries yourself.

Compiling: ./keyboards/ergodox_ez/twimaster.c [ERRORS]

/tmp/ccSlFLOB.s: Assembler messages:
/tmp/ccSlFLOB.s: Warning: can't close .build/obj_ergodox_ez_default/twimaster.lst: Input/output error
/tmp/ccSlFLOB.s: Fatal error: can't close .build/obj_ergodox_ez_default/twimaster.o: Input/output error

tmk_core/rules.mk:373: recipe for target '.build/obj_ergodox_ez_default/twimaster.o' failed
make: *** [.build/obj_ergodox_ez_default/twimaster.o] Error 1

Which seems to indicate that there is a problem writing to the filesystem.

Note that if I run bash instead of the CMD inside the container I can create a file in /tmp or /QMK

If I modify the Dockerfile to ADD . /GMK instead of using volume mounted from the host, the issue doesn’t happen.

2

I report the same issue - 1.12.0-rc3 .

I can echo a simple string to a file mounted on the volume (so it’s not a simple permission error), but can’t create a tar archive (that’s not created even empty/truncated).

1 Like
3

@vitspinka can you share your Dockerfile, sounds like you have a simple isolated example.

Furthermore I realized today than another container I am struggling to get working right on a Mac is due to the same exact issue.

4

Not really a Dockerfile, as I’am building an image from scratch, running chroot.

Run as:
docker run --rm --privileged -i -t -v $PWD:/srv oraclelinux:6 /srv/build.sh

Contents of build.sh is:
#!/bin/bash exec 0<&- set -e -u -x DEST_IMG_TEST="/srv/oel4.tar.gz_test" DEST_IMG="/srv/oel4.tar.gz" basearch=x86_64 releasever=4 instroot=$(mktemp -d) tmpyum=$(mktemp) cat << EOF > ${tmpyum} [main] debuglevel=2 exactarch=1 obsoletes=1 gpgcheck=0 plugins=1 installonly_limit=5 distroverpkg=redhat-release [el4_latest] name=Enterprise Linux $releasever Latest ($basearch) baseurl=http://yum.oracle.com/repo/EnterpriseLinux/EL4/latest/$basearch/ gpgkey=file:///usr/share/rhn/RPM-GPG-KEY-oracle gpgcheck=0 enabled=1 EOF mkdir ${instroot}/{dev,etc,proc} mknod ${instroot}/dev/null c 1 3 touch ${instroot}/etc/fstab yum \ -c ${tmpyum} \ --disablerepo='*' \ --enablerepo='el4_*' \ --setopt=cachedir=${instroot}/var/cache/yum \ --setopt=logfile=${instroot}/var/log/yum.log \ --setopt=keepcache=1 \ --setopt=diskspacecheck=0 \ -y \ --installroot=${instroot} \ install \ redhat-release yum iputils coreutils which curl || echo "ignoring failed yum; $?" /bin/umount ${instroot}/proc echo "1" > ${DEST_IMG_TEST} chroot ${instroot} tar -czf - . > ${DEST_IMG}

This time, a file was actually created, but only about 1MB (it’s supposed to be about 90MB).

5

@vitspinka can you help me craft a small reproducible example?

I tried the following but it worked:

FROM alpine
VOLUME /vol1
WORKDIR /vol1
CMD tar cvzf tar.file.tgz docker-1.12.0-rc4
6

I used dd instead (to have no dependency on the docker installation files):

FROM alpine VOLUME /vol1 WORKDIR /vol1 CMD dd if=/dev/zero of=/vol1/z bs=1M count=1000

And run as
docker build -t e . docker run -v$PWD:/vol1 e

Trying to make it a really reproducible case, I found out it depends on whether the file already exists or not (fails only for non-existent file) and even more importantly, on the location: it fails where the path is in Dropbox, works otherwise.

7

That’s exactly it, something about the project being in Dropbox makes it fail. That’s why it was so hard to narrow down for me, it’s dependent on it being in Dropbox. For some reason Docker & Dropbox have weird interactions when mounting volumes. Not sure why but that’s it

8

Can confirm problem exists on rc4. reproducible by doing a ‘mv’ in the docker container on a large file to the mounted Dropbox folder.

9

I’m seeing the same thing. Today was the first time I put a project in Dropbox and I immediately had problems. I’ve moved everything back out of Dropbox and the issues have gone away.