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
W dniu 21.11.2025 o 15:20, Armin pisze: 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
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: 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
Hey Armin W dniu 26.11.2025 o 13:48, veud@proton.me pisze: Last time I looked apparmor.d DID contain an apparmor profile that was nowhere near being finished. Can you double check that none of those come from a profile like "snapd" or something like that? Snapd is NOT sandboxed by default. Apparmor.d is a 3rd party effort that will take a long time to mature in general, but snapd is even more complex so I think it's best if you could eliminate that as the possiblity. If you don't mind sharing, can you show me all the apparmor denials (anything with DENIED) on snapd start-up? This is when snapd tries to test-mount a toy squashfs file system to ensure it is not broken. I'm testing snapd on Debian with https://github.com/canonical/snapd-smoke-tests/. All of the tests there run in a Debian cloud VM and we have not seen any failures there (but we do not test apparmor.d) If you can help me to understand how to install and enable apparmor.d, we might be able to reproduce the problem. In [1] you can see how a Debian cloud image is initialized with cloud-init - on top of the automatic user needed for testing, we install a few packages including snapd. Then in a test such as [2] we install a snap and ensure this works. We can easily modify that setup to install apparmor.d and see what would happen. Can you help me to understand how you did that on your system? Best regards ZK [1] https://github.com/canonical/snapd-smoke-tests/blob/f5e8b472d3ad04caa9ba219ae87ad4d1b20658f3/.image-garden.mk#L106 [2] https://github.com/canonical/snapd-smoke-tests/blob/f5e8b472d3ad04caa9ba219ae87ad4d1b20658f3/tests/server/hello/task.yaml#L6