Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1271054 > unrolled thread

Bug#1121128: /usr/bin/snap: Unable to install any snaps

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1121128: /usr/bin/snap: Unable to install any snaps Armin <veud@proton.me> - 2025-11-21 15:30 +0100
    Bug#1121128: /usr/bin/snap: Unable to install any snaps veud@proton.me - 2025-11-26 13:50 +0100

#1271054 — Bug#1121128: /usr/bin/snap: Unable to install any snaps

Package: snapd
Version: 2.71-3
Severity: important
File: /usr/bin/snap
X-Debbugs-Cc: veud@proton.me

Dear Maintainer,


What led up to the situation?
I tried to install a snap on Debian 13, and snapd’s syscheck failed because a
test mount succeeded but the canary file couldn’t be read.

What exactly did you do (or not do) that was effective (or ineffective)?
I manually created and mounted a squashfs image, which worked fine, showing the
issue is specific to snapd’s internal mount test. I also verified AppArmor,
cgroups, and user namespace support, all of which appeared correct.

What was the outcome of this action?
Snapd reported no error on the mount, but the canary file was unreadable,
causing snap installations to fail.

What outcome did you expect instead?
I expected snapd’s syscheck to succeed, allowing snaps to install normally, as
manual squashfs mounts work without issue.


Output after the command "snap install hello-world":
error: system does not fully support snapd: squashfs mount returned no err but
canary file cannot be read


-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.48+deb13-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser                                       3.152
ii  apparmor                                      4.1.0-1
ii  ca-certificates                               20250419
ii  dbus-user-session [default-dbus-session-bus]  1.16.2-2
ii  dbus-x11 [dbus-session-bus]                   1.16.2-2
ii  gnupg                                         2.4.7-21
ii  init-system-helpers                           1.69~deb13u1
ii  kmod                                          34.2-2
ii  libapparmor1                                  4.1.0-1
ii  libc6                                         2.41-12
ii  libcap2                                       1:2.75-10+b1
ii  libcap2-bin                                   1:2.75-10+b1
ii  libseccomp2                                   2.6.0-2
ii  libudev1                                      257.9-1~deb13u1
ii  openssh-client                                1:10.0p1-7
ii  squashfs-tools                                1:4.6.1-1
ii  systemd                                       257.9-1~deb13u1
ii  udev                                          257.9-1~deb13u1

Versions of packages snapd recommends:
ii  gnupg  2.4.7-21

Versions of packages snapd suggests:
ii  kdialog  4:25.04.0-1
ii  zenity   4.1.90-1

-- no debconf information

[toc] | [next] | [standalone]

#1271672

Dear Krynicki,


Q: Do you have any AppArmor denials in your system log?
A: Yes, but they are unrelated to snapd’s squashfs mounting. Most denials are from other services (cupsd, Xorg) or snap apps (Emote, Discord). There are no denials directly preventing snapd from mounting snaps.

Q: Anything showing up with DENIED that looks related to snapd?
A: No. The only snapd-related message was a snap-update-ns denial trying to bind mount /boot/, but this does not block normal snap operation. Disabling AppArmor does not make snapd work, indicating AppArmor is not the cause.

Q: Is this a container or bare metal or virtual machine system?
A: Bare metal system (systemd-detect-virt returns "none")

Q: Are you using apparmor.d project with extra AppArmor profiles?
A: Yes, 127 custom profiles are loaded, but they do not appear to block snapd.

Q: Additional notes
A: Snapd failing to mount snaps is likely due to squashfs/mount issues, such as missing kernel support for squashfs or loop devices, snap-confine helper issues, or the snaps being stored on a non-native filesystem. AppArmor does not appear to be responsible.

Best Regards

Armin

Sent from Proton Mail for Android.

-------- Original Message --------
On Wednesday, 11/26/25 at 10:45 Zygmunt Krynicki <me@zygoon.pl> wrote:


W dniu 21.11.2025 o 15:20, Armin pisze:
> Package: snapd
> Version: 2.71-3
> Severity: important
> File: /usr/bin/snap
> X-Debbugs-Cc: veud@proton.me
>
> Dear Maintainer,


Thank you for reporting this issue. At present I'm not quite sure what
is going on. The kernel looks regular, I need to see if I can reproduce
this myself.

You might help me by answering a few questions:

Q: Do you have any apparmor denials in your systmem log?
Q: Anything showing up with DENIED that looks related to snapd?
Q: Is this a container or a bare metal or virtual machine system?
Q: Are you using apparmor.d project with extra apparmor profiles.

I'm sorry for whatever the cause is, I understand this must be
frustrating a little.

Best regards
Zygmunt Krynicki

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web