cannot perform operation: mount --rbind /snap /snap: Permission denied

Bug #1729576 reported by Tom Haddon on 2017-11-02
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Zygmunt Krynicki
snapd (Ubuntu)

Bug Description

I've created a 16.04 LXC from a 16.04 host, installed a snap inside it and am trying to run the snap. When I do so I get the following error:

cannot perform operation: mount --rbind /snap /snap: Permission denied

Here's what's installed inside the LXC:

ubuntu@codetree-snapcraft:~$ snap list
Name Version Rev Developer Notes
codetree 73 2 axino -
core 16-2.28.5 3247 canonical core

ubuntu@codetree-snapcraft:~$ snap --version
snap 2.28.5
snapd 2.28.5
series 16
ubuntu 16.04
kernel 4.10.0-37-generic

ubuntu@codetree-snapcraft:~$ ls -lha /snap/
total 20K
drwxr-xr-x 5 root root 4.0K Nov 2 10:01 .
drwxr-xr-x 22 root root 4.0K Nov 2 09:45 ..
drwxr-xr-x 2 root root 4.0K Nov 2 10:01 bin
drwxr-xr-x 3 root root 4.0K Nov 2 10:01 codetree
drwxr-xr-x 3 root root 4.0K Nov 2 09:46 core

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: snap (not installed)
ProcVersionSignature: Ubuntu 4.10.0-37.41~16.04.1-generic 4.10.17
Uname: Linux 4.10.0-37-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.10
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Nov 2 11:14:59 2017
EcryptfsInUse: Yes
SourcePackage: snap
UpgradeStatus: No upgrade log present (probably fresh install)

Tom Haddon (mthaddon) wrote :
Zygmunt Krynicki (zyga) on 2017-11-02
Changed in snap (Ubuntu):
assignee: nobody → Zygmunt Krynicki (zyga)
Dylan Aïssi (daissi) wrote :

This bug seems not related to the snap package (snap: location of genes from DNA sequence with hidden markov model) but to the snapd package (part of the app packaging system developed by Canonical).

affects: snap (Ubuntu) → snapd (Ubuntu)
CodelyTV (codelytv) wrote :

Same here with Ubuntu 18.04.1 LTS (GNU/Linux 3.13.0-57-generic x86_64):

$ sudo snap install canonical-livepatch
error: cannot perform the following tasks:
- Run configure hook of "canonical-livepatch" snap if present (run hook "configure": cannot perform operation: mount --bind /snap/core/current//etc/nsswitch.conf /tmp/snap.rootfs_7khxxI/etc/nsswitch.conf: Permission denied)

Zygmunt Krynicki (zyga) wrote :


A 3.13 kernel is unsupported. How did you end up using it on Ubuntu 18.04?

Changed in snapd (Ubuntu):
status: New → Incomplete
Oliver B (oliver.b) wrote :

All other users are complaining that the problem occurs if:
1) The /home is a symlink and not a real dir
2) The home folders are not in /home/* but somewhere else like /mnt/data1/home

In my case the home folders are in /home and it is a real dir not a symlink.
The only extra is that the /home is mounted on a different partition than the "/" .
The filesystem root is on /dev/sda1 and the /home is a mount on /dev/sda3.

If I start ubuntu-mate-welcome , it works fine.
If I start ghostwriter-casept , it shows the same error message:

"cannot perform operation: mount --rbind /mnt /tmp/snap.rootfs_ffG8Ui//mnt: Permission denied"

Really interesting...

JPT (j-p-t) wrote :

Yeah, same with me.
$ ll /home
lrwxrwxrwx 1 root root 17 Dez 22 2017 /home -> /media/DATEN/home/
so, any workaround?

$ rclone
2019/02/15 09:22:44.163754 cmd_run.go:502: WARNING: XAUTHORITY environment value is not a clean path: "/media/DATEN/tmp/xauth-1000-_0"
cannot perform operation: mount --bind /tmp/snap.rootfs_HcwGoM /tmp/snap.rootfs_HcwGoM: Permission denied

JPT (j-p-t) wrote :

btw, I've got a clean 18.10 system with recent kernel:
Linux 4.18.0-15-generic #16-Ubuntu SMP Thu Feb 7 10:56:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Zygmunt Krynicki (zyga) wrote :


Can you please report one issue at a time and for each issue related to permission denied on mount, attach the following output:

snap version

dmesg | grep DENIED

Thank you! I will do my best to help.

Zygmunt Krynicki (zyga) wrote :

Oh, since this is done inside a container please also include the command line to spawn a container, including any special changes to security that you may have applied.

Seth Arnold (seth-arnold) wrote :

Does snapd plan to manage /etc/apparmor.d/tunables/home.d/ for users who have moved their home directories? Or are users expected to do this themselves, since non-snap-managed profiles are affected too?


Jamie Strandboge (jdstrand) wrote :

Seth, it is more than just apparmor (it is actually the easiest of the parts to address; snap-confine is harder), but the issue as a whole is tractable, understood and something the snapd team plans to address in the future (perhaps someone from the snapd team can comment).

UndiFineD (k.dejong) wrote :

While true most of the time, root's home directory should actually be read from /etc/passwd

Zygmunt Krynicki (zyga) wrote :

While snapd can read the home directory from the gecos system it is not the technical difficulty preventing the use of arbitrary home directory. This feature is currently unsupported and is listed as such on

I'm sorry for the inconvenience but we had to place those limitations on the user's data location for now. As a workaround you can always mount the desired volume instead of using symbolic links. You can store /home/user anywhere you want as long as you use the mount system to do that. The same goes for /root.

Zygmunt Krynicki (zyga) on 2019-03-25
Changed in snapd:
status: New → Incomplete
assignee: nobody → Zygmunt Krynicki (zyga)
Changed in snapd (Ubuntu):
assignee: Zygmunt Krynicki (zyga) → nobody
Launchpad Janitor (janitor) wrote :

[Expired for snapd (Ubuntu) because there has been no activity for 60 days.]

Changed in snapd (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers