Unable to install core snap in an ephemeral boot: cannot create namespace group directory /run/snapd/ns: Bad file descriptor

Could you please attach the syslog file after the error happens? The strace is nice but unfortunately we would need the strace of the server (snapd) side of the operation. If you want to do that please make sure to use strace -f as go will spawn a lot of processes - and its going to be very chatty :) The syslog is probably sufficient to get a first idea.

Well, that's interesting. The behavior has changed slightly, and I'm not sure why. Now when I install the core snap, I get:

    core 16-2 from 'canonical' installed

(I used to see the same error when installing the core snap.)

Next I tried installing the snap I *really* wanted to install (via `sudo snap install --devmode --edge sonic-lool`) and it still fails; and I see a syslog message very similar to the original error as follows (see like 45 in the paste):

    http://paste.ubuntu.com/24045264/

Based on the syslog message, it looks like a problem with the AppArmor profile's lack of consideration for /overlay/... as a full path in the ephemeral environment. (Not that it should have been obvious!)

> Wiadomość napisana przez Mike Pontillo <email address hidden> w dniu 22.02.2017, o godz. 08:57:
>
> Well, that's interesting. The behavior has changed slightly, and I'm not
> sure why. Now when I install the core snap, I get:
>
> core 16-2 from 'canonical’ installed
This is most likely caused by the removal of the configure hook.

The error only happens when you run any hook/application.

The root of the error is: Feb 22 07:50:32 maas-commission snap[11789]: cannot create namespace group directory /run/snapd/ns: Bad
 file descriptor

I strongly suspect that snap-confine doesn’t work on top of overlayfs. I can investigate this but I cannot offer you any immediate fixes.

>
> (I used to see the same error when installing the core snap.)
>
> Next I tried installing the snap I *really* wanted to install (via `sudo
> snap install --devmode --edge sonic-lool`) and it still fails; and I see
> a syslog message very similar to the original error as follows (see like
> 45 in the paste):
>
> http://paste.ubuntu.com/24045264/
>
> Based on the syslog message, it looks like a problem with the AppArmor
> profile's lack of consideration for /overlay/... as a full path in the

overlayfs doesn’t support apparmor at all, it is not something that we can trivially fix.

> ephemeral environment. (Not that it should have been obvious!)
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1665808
>
> Title:
> Unable to install core snap in an ephemeral boot: cannot create
> namespace group directory /run/snapd/ns: Bad file descriptor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1665808/+subscriptions

Thanks for the reply.

As this is an ephemeral environment (and will as such be destroyed very soon after its creation) I think an acceptable workaround would be to simply disable AppArmor (or portions of it) during this operation.

If I don't hear any additional ideas on this bug report, I'll look into doing that tomorrow.

The following steps allowed me to work around the issue:

sudo apt-get install -yu apparmor-utils
sudo aa-complain /usr/lib/snapd/snap-confine

I'm happy with the workaround, though it would be nice if AppArmor was more flexible, or could improve its UX in some way (such as logging a warning instead of raising an error if someone tries to use it on overlayfs).

UX wise something that might help is running aa-notify from apparmor-notify package that will provide notifications for apparmor denials.

Forgive my ignorance, but isn't aa-notify how we figured out via syslog that AppArmor was causing the problem? Or was that some other mechanism?

I see two options for a better user experience, in order of preference (again, speaking somewhat from ignorance about what's possible here):

(1) Provide a feature (or just make it a default setting, if deemed to be safe) that lets me ignore portions of a profile which can be determined to be unsupported. That way I can keep portions of a profile that will work, but ignore portions that don't make sense for the underlying filesystem.

(2) Allow AppArmor to [log lots of scary warnings and] operate in a warn-only mode if it encounters a filesystem it cannot support, such as overlayfs.

(3) Provide a mechanism to allow me to determine if a particular AppArmor profile will not work because the filesystem is not supported. That way I could write a script to determine if I should invoke the `aa-complain` workaround and disable the profile (which is certain to be hopeless at protecting anything anyway).

We have observed snapd working with aufs on zesty, which is a functionally similar environment -- but is the difference the use of aufs or the use of zesty (most likely the kernel)?