Hi,
I have a weird issue with some snap apps, for example Shotcut works fine, but Freecad, obs-studio stop working and when I try to launch each app I have the message:
cannot get existing device map: Operation not permitted
Maybe anyone know what happen?
Can you provide more information about your system? Specifically attach the output of:
snap version
cat /proc/cmdline
stat -f /sys/fs/cgroup
cat /etc/os-release
systemctl --version
Sorry, I forget it,
snap 2.54.2
snapd 2.54.2
series 16
debian 10
kernel 4.19.0-10-amd64
BOOT_IMAGE=/vmlinuz-4.19.0-10-amd64 root=/dev/mapper/asuszb--vg-root ro quiet mem_sleep_default=deep systemd.unified_cgroup_hierarchy=1 swapaccount=1
File: "/sys/fs/cgroup"
ID: 0 Namelen: 255 Type: cgroup2fs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 0 Free: 0 Available: 0
Inodes: Total: 0 Free: 0
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
systemd 241 (241)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid
Are there any AppArmor denials? dmesg |grep DENIED
Is /sys/fs/bpf
mounted? Provide stat -f /sys/fs/bpf
. If mounted then also sudo ls -l /sys/fs/bpf
.
Everything sounds good:
sudo dmesg |grep DENIED
-> return nothing.
sudo stat -f /sys/fs/bpf
File: "/sys/fs/bpf"
ID: 0 Namelen: 255 Type: bpf_fs
Block size: 4096 Fundamental block size: 4096
Blocks: Total: 0 Free: 0 Available: 0
Inodes: Total: 0 Free: 0
sudo ls -l /sys/fs/bpf
total 0
drwx------ 2 root root 0 Feb 5 22:57 snap
I removed obs-studio and re-installing the backport meanwhile I resolve this. But right now I have:
shotcut snap -> working
riseup-vpn -> working
discord -> failed
freecad -> failed
I don’t know what changed in my OS, but these issues appeared maybe after some update or reboot…
I forget mentioned that I have another issue, when I did some changes on snap apps, for example remove some one or re-install some one, also when I restarted the snap service, every time, Snap did stop my network connection.
And what’s the output of ls -la /sys/fs/bpf/
?
sudo ls -la /sys/fs/bpf/
total 0
drwx-----T 3 root root 0 Feb 5 22:57 .
drwxr-xr-x 7 root root 0 Feb 5 22:48 ..
drwx------ 2 root root 0 Feb 5 22:57 snap
ls -la /sys/fs/bpf/
ls: cannot open directory '/sys/fs/bpf/': Permission denied
Can you run sudo rm -rf /sys/fs/bpf/snap
and try to run the snap as a user again?
Sorry for the delay…
Bad news the same thing…
avp:~$ sudo rm -rf /sys/fs/bpf/snap
avp:~$ snap --version
snap 2.54.2
snapd 2.54.2
series 16
debian 10
kernel 4.19.0-10-amd64
avp:~$ discord
cannot get existing device map: Operation not permitted
I suspect that running discord as a root will actually work.
It looks like your kernel is too old to support user operations of BPF objects. IIRC this was changed in 5.9 or 5.10 kernels. I’m afraid your kernel is a bit too old. Unfortunately BPF and cgroups is bit of a moving target, so if you plan on using cgroups v2 I would strongly recommend updating. In fact Debian 11 is the first release that defaults to cgroup v2.
Is there a particular reason you boot with unified hierarchy?
well yes, it is my laptop and this Debian works perfect around power saving features, the fan and the temperature performance it’s better than the last Debian stable kernel.
On the other hand I already have cgroup v2, and with it I controlling Firefox and other apps, and understand you that its possible that is a little change maybe into the kernels and Snap. But why the others snap works? why only some one fails?
I should be change to another alternative, Linux AppImage or backports… ![:frowning: :frowning:](https://forum.snapcraft.io/images/emoji/twitter/frowning.png?v=12)
Thanks a lot for your time and your help!
Debian 10 is oldstable, 11 should work as first it shipped with cgroup v2 enabled by default so we know that the kernel bits and userspace bits work correctly, and second the cgroup v2 suport is actively tested in snapd upstream CI.
The reason why this happens to some snaps is that cgroup v1 had a separate device controller, with which we could tighten the sandbox and limit the devices a given snap can access. With cgroup v2 there is no separate controller, the feature works by installing a specific type of a BPF program in the cgroup and in fact is dramatically different than the previous method. Only snaps that require access to specific devices are affected by this.
As for Firefox, I’m not really sure how that works in practice. I recall one other user who set up unified hierarchy on Ubuntu 18.04 with really old userspace and things were falling apart too.
Ok, thanks for the explanation. Well, I don’t clarified when mentioned Firefox. I’m running Firefox with cgroup v2 manually, without snap, the official package.
well, a workaround that I found it’s disable this kernel flag. On grub set:
unified_cgroup_hierarchy=0
With that the snaps that was failing, now works again, but I lost some features like launch systemd-run units with strict memory configurations, but I don’t need change my kernel ![:slight_smile: :slight_smile:](https://forum.snapcraft.io/images/emoji/twitter/slight_smile.png?v=12)