Comment 5 for bug 1574556

I'm not sure if it's the same bug, but I'm going to comment here.

I'm using an encrypted home folder.
Snapd was working fine for me until recently. Running any snap now fails with the error:

    failed to create user data directory. errmsg: Permission denied

And these three lines are appended to the journal/syslog:

    Jun 13 21:42:32 bruno-laptop audit[7747]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/bruno/.Private/" pid=7747 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
    Jun 13 21:42:32 bruno-laptop kernel: audit: type=1400 audit(1465850552.422:64): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/bruno/.Private/" pid=7747 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
    Jun 13 21:42:32 bruno-laptop kernel: ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]

As I said, it was working fine.
I don't know if this issue appeared in an update or due to something I did (no idea what it could be).
The issue doesn't seem to be specific to snapd, since my custom AppArmor profiles for other stuff were also affected.

I checked the changes done to ubuntu-core-launcher's AppArmor profile in Yakketty, and they almost work for me. The ".Private" folders themselves also needed read access.
I.e.:

    # Workaround https://launchpad.net/bugs/359338 until upstream handles
    # stacked filesystems generally.
    # encrypted ~/.Private and old-style encrypted $HOME
    owner @{HOME}/.Private/ r,
    owner @{HOME}/.Private/** mrixwlk,
    # new-style encrypted $HOME
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/ r,
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,