snaps don't work with encrypted home: failed to create user data directory. errmsg: Permission denied

Bug #1592696 reported by Redmar on 2016-06-15
This bug affects 46 people
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
ubuntu-core-launcher (Ubuntu)
Jamie Strandboge

Bug Description

No snaps appear to work with encrypted home. For example, even the 'hello' snap does not function: failed to create user data directory. errmsg: Permission denied

The error message appears to be a bit misleading, since the ~/snap/hello/1 directory tree is created, so the snap can access the home dir.

Install without encrypted home, if you do that snaps work properly.

However, see this comment for a possible workaround:

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: snapd 2.0.5
ProcVersionSignature: Ubuntu 4.4.0-24.43-generic 4.4.10
Uname: Linux 4.4.0-24-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jun 15 10:02:35 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-01-01 (165 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151209)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

Redmar (redmar) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu):
status: New → Confirmed
Simon Quigley (tsimonq2) wrote :

This is also a problem in Yakkety.

Jamie Strandboge (jdstrand) wrote :

For the yakkety system, what is the output of 'grep DEN /vag/log/syslog'?

Redmar (redmar) wrote :

This is from a fresh install of the latest yakkety in virtualbox:

$ grep DEN /var/log/syslog
Jun 15 18:49:41 test-VirtualBox kernel: [ 90.415758] audit: type=1400 audit(1466009381.034:41): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/test/.Private/" pid=2345 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

I already commented in
I posted a log in there.

The fix (and workaround) is to add these lines to the end of the file /etc/apparmor.d/usr.bin.ubuntu-core-launcher, before the closing bracket ('}'):

    # Workaround 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,

And then reboot OR install the package "apparmor-utils" and run this command in a terminal:

    sudo aa-enforce /etc/apparmor.d/usr.bin.ubuntu-core-launcher

I'm using this fix and Snappy is now working fine for me.


These lines:

    owner @{HOME}/.Private/ r,
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/ r,

are not present in the update done to Yakketty, but it seems they are needed.

By the way, those lines are also not present in /etc/apparmor.d/abstractions/base.
That file is included by the apparmor profiles generated for each snap (but not by ubuntu-core-launcher).
Please check this as well. This issue may affect more than just Snappy!


I'm on 16.04. Snappy was working fine for me, but this issue appeared a few days ago.
So maybe an update broke this?

Jamie Strandboge (jdstrand) wrote :

For the workaround, simply use:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher

No need to reboot and no need to install apparmor-utils.

As for the timing of the fix-- the snappy team is making some fairly large changes to the launcher which is why the fix for this is not present yet in 16.04. The fix is queued though and I'm told the launcher changes will land with snapd 2.0.9 or possibly 2.0.10 (ie, either the next SRU or the one immediately following).

Jamie Strandboge (jdstrand) wrote :

As for the yakkety denial, it looks like a rule was missed. I'll make sure that is fixed in yakkety and queued for the next SRU.

Changed in snapd (Ubuntu):
status: Confirmed → Invalid
Changed in ubuntu-core-launcher (Ubuntu):
status: New → In Progress
assignee: nobody → Jamie Strandboge (jdstrand)
Jamie Strandboge (jdstrand) wrote :

Uploaded to yakkety and queued in snap-confine. Syncing with mvo and zyga on timing of those other changes to see if the ecryptfs issues should be separate SRU.

Changed in ubuntu-core-launcher (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntu-core-launcher - 1.0.29+1ubuntu1

ubuntu-core-launcher (1.0.29+1ubuntu1) yakkety; urgency=medium

  * debian/usr.bin.ubuntu-core-launcher: add a couple more workaround rules
    for ecryptfs (LP: #1592696)

 -- Jamie Strandboge <email address hidden> Thu, 16 Jun 2016 09:02:53 +0300

Changed in ubuntu-core-launcher (Ubuntu):
status: Fix Committed → Fix Released
Redmar (redmar) wrote :

I have tried the fix in #8 on 16.04 with encrypted home, but I still get the same error:

redmar@raider:~$ sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
redmar@raider:~$ hello
failed to create user data directory. errmsg: Permission denied
redmar@raider:~$ which hello

Leo Francisco (georgeowell) wrote :

Yep, I'm still affected by this also.

Bruno Nova (brunonova) wrote :

@Redmar, have you modified /etc/apparmor.d/usr.bin.ubuntu-core-launcher according to comment #7 before running that command?

Carlos Estrada (chemnic) wrote :

Is this going to be fixed in xenial? or just yakkety? I'm more comfortable with a package update than a workaraund.

> Wiadomość napisana przez Carlos Estrada <email address hidden> w dniu 17.06.2016, o godz. 20:46:
> Is this going to be fixed in xenial? or just yakkety? I'm more
> comfortable with a package update than a workaround.

This will be fixed in both denial and yakkety.

@Bruno Nova,

I'm sorry, I misread the apparmor_parser comment, and thought I only had to run apparmor_parser. After modifying /etc/apparmor.d/usr.bin.ubuntu-core-launcher as described in #7 running the apparmor_parser fixed snaps for me.

Thanks a lot for this workaround, now I can start using snaps again!

ilaiho (ilaiho) wrote :

Doesn't "Fix Released" mean it is already pushed into repository? That is definitely not the case now what it comes to Xenial.

Martin Pitt (pitti) wrote :

There are a looot of changes in this, including a completely new build system, which don't match the usual SRU policy. Please add the missing SRU test case, an analysis of the regression potential, and point to a test plan to ensure that there are no regressions on existing xenial systems.

Changed in ubuntu-core-launcher (Ubuntu Xenial):
status: New → Incomplete
Martin Pitt (pitti) wrote :

Sorry, "this" == upload sitting in the xenial-proposed SRU review queue.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu Xenial):
status: New → Confirmed
Iiro Laiho (iiro) wrote :

@Martin Pitt,

What about the patch in comment #7? It shouldn't be a too big change for a SRU?

Jamie Strandboge (jdstrand) wrote :

@liro, the full set of snap-confine changes need to land since they are needed for a lot of other important snappy work and the snappy team will do what it takes to make them land. AIUI, the snappy team is actively working on landing snap-confine 1.0.36 (which has the fix for this bug) and they'll get all the SRU paperwork and testing in order and hopefully land this soon.

Steven (svanpoeck) wrote :

@brunonova + @gdstrand: Thanks, that did it for me.

Linux 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

ubuntuchi (ubuntuchi) wrote :

This is too bad: Snap apps even don't run ...

Linux: 4.4.0-31-generic #50-Ubuntu SMP x86_64 GNU/Linux
Description: Ubuntu 16.04.1 LTS
snap 2.0.10
:~$ vlc
failed to create user data directory. errmsg: Permission denied
:~$ sudo vlc
sudo: vlc: command not found

It has to be fixed as a soon update, not as changing files by all users!

Jamie Strandboge (jdstrand) wrote :

FYI, this is fixed in the snap-confine that is in xenial-proposed and so it will hopefully be fixed for all 14.04 LTS users soon. In the meantime if you don't want to install proposed packages, the workarounds listed in this report continue to work. I'll list the complete workaround here:

1. make sure /etc/apparmor.d/usr.bin.ubuntu-core-launcher has:
    owner @{HOME}/.Private/ r,
    owner @{HOME}/.Private/** mrixwlk,
    # new-style encrypted $HOME
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/ r,
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,

2. load the updated profile into the kernel with: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher

Keep in mind if you switch back and forth from snap-confine in xenial-proposed and ubuntu-core-launcher that is in the archive, you may have to reapply the above.

Jamie Strandboge (jdstrand) wrote :

Err, I of course meant "will hopefully be fixed for all 16.04 LTS users soon"

David (dave400) wrote :

Any fix for Ubuntu version 16.04?

Jamie Strandboge (jdstrand) wrote :

Still waiting on snap-confine to land (it is in xenial-proposed)-- you can install snap-confine and ubuntu-core-launcher from and it will work.

Łukasz Zemczak (sil2100) wrote :

Installing snap-confine and ubuntu-core-launcher from xenial-proposed resolved my issues, looking good. On the pending SRU page I don't see this bug being marked as fixed by the upload, but from my POV this can be considered as 'verification-done'.

summary: - snaps dont work with encrypted home: failed to create user data
+ snaps don't work with encrypted home: failed to create user data
directory. errmsg: Permission denied
Tony Espy (awe) wrote :

Installing the proposed packages worked for me, albeit with an extra hoop of running a snap app as sudo first to get around the permission problem.

After the installing, I did:

% sudo snap install hello
% hello
mkdir: cannot create directory ‘/home/espy/snap/hello’: Permission denied
% sudo /snap/bin/hello
Hello, world!
% hello
Hello world!

Jamie Strandboge (jdstrand) wrote :

Thanks for testing Tony. Regarding /home/espy/snap/hello that is bug and separate from this update and I think that will be fixed once snap-confine passes SRU and bug #1611063 is addressed.

Morten F. Rasmussen (mofi) wrote :

I also ran into this problem trying out the htop snap. After removing the snap I installed htop via apt, but it still failed with the same message:

$ htop
failed to create user data directory. errmsg: Permission denied
$ which htop

Enabling xenial-proposed and running apt upgrade fixed the problem.

Todor Velichkov (tosho) wrote :

I was missing /etc/apparmor.d/usr.bin.ubuntu-core-launcher so I created one and pasted:
    owner @{HOME}/.Private/ r,
    owner @{HOME}/.Private/** mrixwlk,
    # new-style encrypted $HOME
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/ r,
    owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,
but when I run "sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher" I got error:
"AppArmor parser error for /etc/apparmor.d/usr.bin.ubuntu-core-launcher in /etc/apparmor.d/usr.bin.ubuntu-core-launcher at line 4: syntax error, unexpected TOK_OWNER, expecting $end"

tosho@T440:~$ snap --version
snap 2.24.1
snapd 2.24.1
series 16
ubuntu 16.04
kernel 4.11.0-041100-generic

Jamie Strandboge (jdstrand) wrote :

@Todor, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is no now longer used and the file to modify is now /etc/apparmor.d/usr.lib.snapd.snap-confine.real (there have been several packaging changes since this bug was filed with the move of ubuntu-core-launcher being renamed to snap-confine and moving to the snapd package).

Todor Velichkov (tosho) wrote :

@Jamie ,
so what should I do?
I removed /etc/apparmor.d/usr.bin.ubuntu-core-launcher and copy-paste the code in /etc/apparmor.d/usr.lib.snapd.snap-confine.real and run sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real and the problem still persist. Also installed snap-confine (no difference)

Jamie Strandboge (jdstrand) wrote :

@Todor, can you please:

1. paste the denials you are seeing
2. attach /etc/apparmor.d/usr.lib.snapd.snap-confine.real
3. list the steps to reproduce including how your setup the encrypted dir

Todor Velichkov (tosho) wrote :

I got "cannot change profile for the next exec call: No such file or directory" for all installed snaps.
I've encrypted my $HOME during clean install of 16.04 a year ago. At the beginning I thing snaps worked, later something messed up.

Jamie Strandboge (jdstrand) wrote :


The profile you attached compiles fine. Did you adjust any files in /etc/apparmor.d/abstractions/*?

Can you attach the the tar file from the following command?

$ sudo tar -zcvf lp1592696.gz /etc/apparmor.d /var/lib/snapd/apparmor/profiles

Todor Velichkov (tosho) wrote :

 I don't think so.

Andrew Pam (xanni) wrote :

I still have the same issue:

$ snap --version
snap 2.39.3
snapd 2.39.3
series 16
ubuntu 18.04
kernel 5.0.0-21-generic

[ 5625.716224] ecryptfs_dir_open: Error attempting to initialize the lower file for the dentry with name [/]; rc = [-13]
[ 5625.716249] audit: type=1400 audit(1562807980.057:295): apparmor="DENIED" operation="open" profile="/snap/core/7270/usr/lib/snapd/snap-confine" name="/data/home-Xenial/.ecryptfs/xanni/.Private/" pid=25242 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers