Arch Linux User Repository

Package update notes

2.36

2.36 is the first release with AppArmor enabled by default on Arch.

If you do not have AppArmor enabled at boot there should be no functional changes visible.

If you wish to use snaps with Apparmor, first make sure that Apparmor is enabled during boot, see https://wiki.archlinux.org/index.php/AppArmor for details. After upgrading the package, you need to do the following steps:

• Reload the profiles: systemctl restart apparmor.service
• Restart snapd: systemctl restart snapd.service
• Load profiles for snaps: systemctl enable --now snapd.apparmor.service

2.62

Since 2.62 snapd generated additional files describing the sandbox. The snapd service needs to be restarted after the update for snaps to continue working (unless the system is rebooted after the update, in which case no additional steps are needed). To restart, run systemctl restart snapd.service

2.70

Snapd 2.70 drops setuid permissions on /usr/lib/snapd/snap-confine in favor of explicit file capabilities. After an upgrade to 2.70, the users are prompted to restart the apparmor.service otherwise attempts to run snaps will error with cannot set capabilities message.

@Brian2026 I'm sorry but please refrain from posting random output generated by Claude, or at least verify it before posting.

RestrictFileSystems is empty, nothing is denied. PrivateMounts is not set by default.

$ systemctl show -p RestrictFileSystems -p PrivateMounts snapd.service
PrivateMounts=no
RestrictFileSystems=~

The model is clearly making this up. I would strongly advise you to refrain from posting random snippets that rewrite service units. People may break their systems if they copy them blindly.

However, what could be causing this apparmor.d, but it's even not in Arch repositories and you need to install it explicitly from AUR. I heard there are compatibility problems with some tools. but I'm not using it myself and cannot comment. However, looking at https://github.com/roddhjav/apparmor.d/blob/f8de8d248ba607d48c8f3e798b19cd35f814d71c/apparmor.d/groups/snap/snapd#L47 the mount in question is allowed, and it's been like this for the last 3 years. If it really is prevented by AppArmor, you would see a denial in dmesg/journal. Do you see one?

Next, since it's related to mounts, you may add the following drop in file to debug this further:

[Service]
Environment=LIBMOUNT_DEBUG=all

restart snapd. You should see a very long log from libmount when snapd probes squashfs support. Perhaps it contains some useful output or a hint what's wrong.

I'm sorry, but I don't run CachyOS so can't help you much with that. You can try posting in snapcraft forum.

Continued:

Summary

| Cause | Effect | Fix | |---|---|---| | systemd 260 bpf-restrict-fs | Blocks squashfs post-mount operations | RestrictFileSystems= in service override | | apparmor.d snapd profile conflict | Mount namespace disconnected path error | aa-disable snapd | | Package updates overwrite fix | snapd breaks again after update | pacman hook to restore fix automatically |

Notes

• This issue affects CachyOS installations with systemd 260+ and the apparmor.d package installed alongside snapd.
• Removing bpf from the kernel LSM list (lsm= kernel parameter) is not recommended — it is required for CachyOS's AppArmor BPF enforcement to work correctly.
• The /snap -> /var/lib/snapd/snap symlink should already exist on CachyOS. If not: sudo ln -s /var/lib/snapd/snap /snap

@bboozzoo I was able to run snap download hello-world and I was able to successfully mount the snap with `sudo mount -t squashfs hello-world_*.snap /mnt'.

This confirmed that squashfs was working; I confirmed that the squashfs module was loaded.

I did some more digging/excavating with the help of Claude and I was able to find out what was going on.

Note that this was for CachyOS; I don't have a regular Arch Linux system to test this.

Fixing Snapd on CachyOS (systemd 260 + apparmor.d)

The Problem

After a fresh CachyOS install, snapd fails with:

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/syscheck-mountpoint-XXXXXXXXXX: filesystem was mounted, but any subsequent operation
       failed: Operation not permitted.

And snapd.service fails to start with Result: protocol.

Root Causes

There are two separate issues that combine to break snapd. Both are introduced by packages that may not have been present in older CachyOS installs.

1. systemd 260 — bpf-restrict-fs

systemd 260 introduced a new security feature called bpf-restrict-fs. At boot, systemd loads a BPF LSM (Linux Security Module) program that enforces filesystem restrictions globally across all services. By default, services that don't explicitly declare RestrictFileSystems= in their unit file get a restrictive policy that blocks squashfs mount operations — specifically any filesystem operation performed after the mount itself (such as ls, stat, or getattr).

Snapd performs a "syscheck" at startup: it creates a temporary squashfs image, mounts it, and tries to access it. The mount itself succeeds, but the subsequent ls fails with Operation not permitted because the BPF LSM blocks it.

This affects snapd because its unit file predates systemd 260 and doesn't declare RestrictFileSystems=. The fix is to explicitly clear this restriction for the snapd service.

2. The apparmor.d package — conflicting snapd AppArmor profile

The apparmor.d package (which provides 1500+ AppArmor profiles) ships its own /etc/apparmor.d/snapd profile. This conflicts with snapd's own dynamically self-managed AppArmor profile. When both are active, snap's mount subprocess runs in a different mount namespace than expected, and AppArmor sees the squashfs mountpoint as a "disconnected path" — a path it cannot resolve — and blocks access to it.

The apparmor.d snapd profile was not designed for the way CachyOS/Arch snapd manages its AppArmor profiles and causes this mount namespace conflict.

The Fix

Step 1 — Create a systemd override for snapd

This clears the restrictive filesystem policy and disables private mount namespacing for snapd:

sudo mkdir -p /etc/systemd/system/snapd.service.d/
sudo tee /etc/systemd/system/snapd.service.d/override.conf << 'EOF'
[Service]
RestrictFileSystems=
PrivateMounts=no
EOF

Step 2 — Disable the conflicting AppArmor profile

This disables the apparmor.d package's snapd profile, allowing snapd to manage its own AppArmor profiles as intended:

sudo aa-disable snapd

Step 3 — Apply changes and test

sudo systemctl daemon-reload
sudo systemctl enable --now snapd.apparmor
sudo systemctl enable --now snapd.socket
sudo systemctl enable --now snapd.service
sudo snap install hello-world
hello-world

You should see:

Hello World!

Step 4 — Add snap binaries to your PATH

Fish shell:

fish_add_path /var/lib/snapd/snap/bin

Bash/Zsh — add to /etc/environment:

echo 'PATH="/var/lib/snapd/snap/bin:$PATH"' | sudo tee -a /etc/environment

Then log out and back in.

Making the Fix Permanent (survives package updates)

When snapd, apparmor, or apparmor.d are updated or reinstalled by pacman, the override.conf can be overwritten and the AppArmor profile re-enabled. Create a pacman hook to automatically restore the fix after any such update:

sudo mkdir -p /etc/pacman.d/hooks
sudo tee /etc/pacman.d/hooks/snapd-override.hook << 'EOF'
[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = snapd
Target = apparmor
Target = apparmor.d

[Action]
Description = Restoring snapd systemd override and disabling conflicting AppArmor profile...
When = PostTransaction
Exec = /bin/bash -c 'mkdir -p /etc/systemd/system/snapd.service.d && echo -e "[Service]\nRestrictFileSystems=\nPrivateMounts=no" > /etc/systemd/system/snapd.service.d/override.conf && ln -sf /etc/apparmor.d/snapd /etc/apparmor.d/disable/snapd && systemctl daemon-reload'
EOF

@Brian2026 works for me on Arch with:

$ uname -a Linux galeon 7.0.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000 x86_64 GNU/Linux

Does your kernel support squashfs? I would run snap download hello-world and then try to mount -t squashfs hello-world_*.snap /mnt to check if it works at all.

Error as of 2.75:

sudo snap install hello-world error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/syscheck-mountpoint-978930249: filesystem was mounted, but any subsequent operation failed: Operation not permitted.

I'm using the CachyOS kernel 7.0.3. This could be an EPERM issue that's built into the kernel.

@Sophie-s1 upstream only supports Go, there are no plans to support gcc-go.

makepkg fails when using gcc-go (15.2.1) but succeeds when using the go compiler. I've only tested on Cachy OS, and not a vanilla Arch install.

There are easy work arounds until newer versions come out

@mpark thanks, I know, but I'm waiting for 2.74.1 to be finally available.

New snapd available

Version: 2.74 Sha256: ed034744915fe538b3b67d9bcaf4d28cf5fe8bf75914da4a887ae393d9931ebc