Thanks for your reporting.
I hit this problem too when I changed the default storage driver from aufs -> btrfs.
Jan 2 14:42:41 VBox kernel: [10586.144283] audit: type=1400 audit(1514875361.547:224): apparmor=“DENIED” operation=“mkdir” profile=“snap.docker.dockerd” name="/temp-docker-extract625899634/" pid=10465 comm=“exe” requested_mask=“c” denied_mask=“c” fsuid=0 ouid=0
Jan 2 14:42:41 VBox docker.dockerd[9657]: time=“2018-01-02T14:42:41.624544086+08:00” level=debug msg=“Cleaning up layer afc87d762f6722ef3b8610900570ebb7d08cb97a193d62a30116d18185d7b86d: ApplyLayer exit status 1 stdout: stderr: mkdir /temp-docker-extract625899634: permission denied”
For now, we only have a few storage backends(aufs, overlay, zfs) supported in docker snap to make sure it works well both on core and classic. I’ll investigate it and put any updates in this thread.
Thanks
I take a closer look at this problem.
I am not sure if pivot_root works as expected in snappy. But it looks to me that daemon actually still lives in old root even after pivot_root, which causes apparmor denial(make a dir under ‘/’) during applying the layer.
Probably, it was a duplicate or something related to the following issues
These issues not only exist in overlayfs, but also in btrfs. Thanks @jdstrand for the example code for the bug reproduce.
A quick workaround is using the realChroot directly in snappy. Using the realChroot is the default method for docker daemon to change root in unix and fallbacks in linux once an error occurs during pivot_root
A newer version of 17.06(17.06.2-ce-1 rev: 237) has been uploaded to edge channel of latest/17.06. @lucyllewy could you help to test it under your environment?
Here is how I tested 17.06.2-ce-1 on classic(16.04) with btrfs storage backend enabled.
A slight difference from your environment, I created a dedicated block device as a btrfs filesystem and manually mounted it to docker snap root dir: /var/snap/docker/common/var-lib-docker
