[SOLVED, for now] sudo snap install gimp [fails]

TL;DR I had moved my /root directory onto the /home partition to ensure its contents are respected (too) between reinstalls. Snap notices stuff like that and won’t go along with it.


$ sudo snap install gimp

error: cannot perform the following tasks:

  • Run install hook of “gimp” snap if present (run hook “install”: cannot perform operation: mount --rbind /root /tmp/snap.rootfs_XOSjpI//root: Permission denied)

I, as root, would like to know just what process thinks “it” can deny(?), Me, permission(?) to, well, anything, anywhere on My machine. (So I can kill it. A lot. And then pour salt on it.)

Other than that, I’m completely over it and could use some advice how to proceed.

Thank you.

Should add:
Ubuntu 18.04

# ls -lRa /tmp/snap.rootfs_XOSjpI/
total 8
drwx------  2 root root 4096 Apr 10 06:54 .
drwxrwxrwt 28 root root 4096 Apr 10 06:55 ..

This looks like it might be a snapd issue. @zyga-snapd have you seen this before? It looks like snapd is unable to implement the complete mount namespace before running the hooks. (the GIMP install hook does not call mount, so the error is not actually coming from the hook itself).

@DavidOertl, would it be possible for you to post the output of running the following command in a terminal, please?

snap version
# snap version
snap    2.44.1
snapd   2.44.1
series  16
ubuntu  18.04
kernel  5.3.0-46-generic

# apt install snap
snapd is already the newest version (2.42.1+18.04).

[Incidentally that must be some kind of Olympic record for response time… ;^) ]

1 Like

Thanks for posting the followup :slight_smile:

For the response time, it helps that I know the GIMP package inside-and-out so I can help guide the snapd devs toward a more meaningful investigation…

Hello

Can you please provide some additional information:

dmesg | grep DENIED
ls -ld /root
sudo aa-status

Thanks

1 Like

I tried a few times, so there’s a lot; to reduce clutter, here’s the last:

# dmesg | grep -i denied | grep snap.rootfs_XOSjpI

[53349.522661] audit: type=1400 audit(1586519657.856:176): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/snap/core/8935/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_XOSjpI/root/" pid=14226 comm="snap-confine" srcname="/home/root/" flags="rw, rbind"
1 Like

Is your root user’s home directory /home/root? Do you have a symlink /root -> /home/root?

Wow. (yes… I actually do.)

“But it’s a new thing. I just started doing that with this install. And I did it for a Very Good Reason: I noticed that when I re-installed just days ago that although I had taken steps to preserve all my user accounts info by having a separate “/home” partition, the “/root” directory was trashed, and I lost very important how-to notes I had saved there, of interest to user root.”

Famous Last Words:
“There, I fixed it.”

Good eye.

But having said that, “I sure would like to keep it /root, the pointer to /home/root.” but will happily accept why I may not.

Thank you.

I can see why this might be a problem…

$ ls -ld /root
lrwxrwxrwx 1 root root 10 Apr  8 17:06 /root -> /home/root

$ ls -lR /home/root
ls: cannot open directory '/home/root': Permission denied

$ sudo ls -lR /home/root
/home/root:
total 4
drwxr-xr-x 3 root root 4096 Apr  9 12:41 snap

/home/root/snap:
total 4
drwxr-xr-x 2 root root 4096 Apr 10 06:55 gimp

/home/root/snap/gimp:
total 0
lrwxrwxrwx 1 root root 3 Apr  9 12:41 current -> 252

“I un-fixed it.” and moved /home/root back to /.

% sudo snap install gimp

worked as expected, thankyouverymuch.

BUT…

I’ll work around it, but if keeping /root on the home partition in order to preserve it between installs is a Bad Idea, someone please explain.

Thank you.

To keep your /root files in /home/root you can add this to /etc/fstab:

/home/root /root bind defaults 0 0

That will bind-mount the /home/root dir to /root so you can keep using /root as the root user’s home directory but the files will actually be saved to /home/root. This is better (for snaps) than a symlink because the files are actually exposed as though they were really in /root so apparmor doesn’t complain. Apparmor cannot follow symlinks, but bind mounts are good as a workaround for the same concept.

1 Like