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

[Tom Haddon]

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)

[Dylan Aïssi (daissi)]

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).

[CodelyTV (codelytv)]

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)]

Hello

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

[Oliver B (oliver.b)]

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)]

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)]

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)]

Hello

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)]

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)]

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?

Thanks

[Jamie Strandboge (jdstrand)]

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)]

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

[Zygmunt Krynicki (zyga)]

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 https://forum.snapcraft.io/t/limitations-in-snapd/9718

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.

[Launchpad Janitor (janitor)]

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

[A (launch123)]

Still exists in 20.04 - no attempt has been to fix this
The issue is simply when /root/ is a soft link

Preparing to unpack .../chromium-browser_1%3a85.0.4183.83-0ubuntu0.20.04.2_amd64.deb ...
=> Installing the chromium snap
==> Checking connectivity with the snap store
==> Installing the chromium snap
error: cannot perform the following tasks:
- Run configure hook of "chromium" snap if present (run hook "configure": cannot perform operation: mount --rbind /root /tmp/snap.rootfs_mKHbYk//root: Permission d
enied)
dpkg: error processing archive /var/cache/apt/archives/chromium-browser_1%3a85.0.4183.83-0ubuntu0.20.04.2_amd64.deb (--unpack):
 new chromium-browser package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/chromium-browser_1%3a85.0.4183.83-0ubuntu0.20.04.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)