Call for testing of the docker snap


It could be made to and if it did, then once we were sure that all the processes were killed, snapd could unload the profiles. I believe this was always the intent, but it doesn’t do it yet.

[WIP] Refresh App Awareness

A workaround for this bug on Ubuntu Core 16 is to change the overlay2 storage-driver back to aufs:

In short terms

$ sudo sed -i ‘s/overlay2/aufs/’ /var/snap/docker/current/config/daemon.json
$ sudo snap restart docker




With storage-driver overlay2

$ sudo docker run hello-world

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete 
Digest: sha256:92695bc579f31df7a63da6922075d0666e565ceccad16b59c3374d2cf4e8e50e
Status: Downloaded newer image for hello-world:latest
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"rootfs_linux.go:109: jailing process inside rootfs caused \\\"permission denied\\\"\"": unknown.

$ sudo su
root$ journalctl --no-pager -e -k | grep apparmor | grep -v kmod | grep snap.docker.dockerd

Apr 25 21:50:47 localhost.localdomain kernel: audit: type=1400 audit(1556229047.116:15): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.docker.dockerd" pid=1374 comm="apparmor_parser"
Apr 25 21:50:52 localhost.localdomain kernel: audit: type=1400 audit(1556229052.260:46): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.docker.dockerd" pid=1547 comm="apparmor_parser"
Apr 25 21:50:57 localhost.localdomain kernel: audit: type=1400 audit(1556229057.708:88): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.docker.dockerd" pid=1771 comm="apparmor_parser"
Apr 25 21:51:01 localhost.localdomain kernel: audit: type=1400 audit(1556229061.208:97): apparmor="STATUS" operation="profile_load" profile="snap.docker.dockerd" name="docker-default" pid=1856 comm="apparmor_parser"
Apr 25 21:55:23 localhost.localdomain kernel: audit: type=1400 audit(1556229323.728:103): apparmor="DENIED" operation="open" profile="snap.docker.dockerd" name="/system-data/var/snap/docker/common/var-lib-docker/overlay2/6cba9d1d59f62094649efe897713fade57986b030ed22a80210053af583c49fc/diff/" pid=2110 comm="runc:[2:INIT]" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Change the docker storage-driver overlay2 to aufs

$ sudo sed -i ‘s/overlay2/aufs/’ /var/snap/docker/current/config/daemon.json
$ sudo snap restart docker

With storage-driver aufs

$ sudo docker run hello-world

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete 
Digest: sha256:92695bc579f31df7a63da6922075d0666e565ceccad16b59c3374d2cf4e8e50e
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:

For more examples and ideas, visit:


Hi, I would like to use the docker snap. However, I don’t want to put everything in my home folder. (Since that is on a NVME SSD)
So I thought I could just make a symlink in my home to point to somewhere else, but I guess the confinement is too smart for that? Because it does not seem to work.
If you could confirm this, then I shall need to move to normal docker again.


It should be smart enough to be able to use a bind-mount instead of a symlink (that usually works for other snaps, but docker might be special here) :wink:


@ogra is correct, you can use a bind-mount of your data from outside of the home folder to somewhere in your home folder


I fear I don’t really understand. :slight_smile:
But I also see that I might not have explained my situation well enough.

So I have the docker snap running.
Then I want to run gitlab in a docker container.
Normally I use volumes and specify something like this:
To mount the directory directory of the host in the container.
That does not work with the snap, since it can only access things in ~/.

If I do /home/user/gitlab/config:/etc/gitlab all works as expected.
However, if /home/user/gitlab is a symlink to say /opt/gitlab it does not work anymore.

I think you are referring to adding a bind-mount to the snap yaml, but I would rather not build my own. But then again, I just might not understand what you mean. :slight_smile:


For your example of /opt/gitlab/config, you would (as root) perform a bind mount that gives /home/user/gitlab/config a view into /opt/gitlab/config, that is to say run:

$ sudo mount --bind /opt/gitlab/config /home/user/gitlab/config

Note this will only last for your current session, to perform this at every boot, you can add an entry to your /etc/fstab like this:

/opt/gitlab/config /home/user/gitlab/config none defaults,bind 0 0

Note that the above was not tested so you may need to adjust it slightly, etc.


Ah, thanks! I only knew about bind mounts in the context of containers. :slight_smile:


@ijohnson why lxd snap has not this limitation? We can mount disk from everywhere with it.

Using home or media to access things does not mean this is more secure: do you know what files are in media or home? NO. Only ops know it.

You should not try to replace ops job.


we do know that these (/home and /media/$USER/) are typically the only places a user can access without privilege escalation in a default install, so snapd gained interfaces to allow acces to these dirs to be able to access user data.


I think i missed something.

Lxd snap, which has some privileges, can create unprivileged containers which can access anything on the host filesystem, if you mount it on the container.

What prevents docker snap to do the same?


LXD has a special interface specifically for its use called lxd-support. This is likely providing different rules than the docker snap is gaining.


ok but why 2 container providers , packaged as snaps by canonical, doing globally the same thing, don’t use the same tips to create containers as simply as possible ?

why one is complicated and one is not, since canonical is buidling them 2?


Can’t get the docker snap to work. After reading this whole thread and trying various things, still no joy. I’m running on btrfs for my filesystem and have tried “overlay2” and “btrfs” storage drivers as well as the default.

Seem to get the furthest with the --edge channel for docker and the overlay2 driver - I can get a sensible response from docker info, but docker run hello-world fails on all drivers.

All throw differing errors.

⚡ snap info core
name:      core
summary:   snapd runtime environment
publisher: Canonical✓
license:   unset
description: |
  The core runtime environment for snapd
type:         core
snap-id:      99T7MUlRhtI3U0QFgl5mXXESAiSwt776
tracking:     stable
refresh-date: 9 days ago, at 12:21 BST
  stable:    16-2.40                      2019-08-12 (7396) 92MB -
  candidate: 16-2.40                      2019-07-17 (7396) 92MB -
  beta:      16-2.41~pre1                 2019-08-20 (7640) 93MB -
  edge:      16-2.41~pre1+git1439.bebc78f 2019-08-22 (7654) 93MB -
installed:   16-2.40                                 (7396) 92MB core

I’m happy to try and debug this further, but there seems to be so many variables I’m not sure where to start.