Snap is not in the official Arch Linux repositories, so on Arch you build snapd from the AUR, while Manjaro ships it ready to install. Either way the package alone isn’t enough. You still have to start the socket, create the /snap link that classic snaps need, and decide whether you want AppArmor, because without it snaps run with only part of their sandbox.
This guide shows you how to install Snap on Arch Linux and Manjaro, run your first snaps, enable AppArmor confinement, manage channels and refreshes, and remove snapd without leaving dead links behind. We tested every step on Arch Linux with kernel 7.2.9 and snapd 2.78 from the AUR, and checked the Manjaro package (snapd 2.76.2 on Manjaro 26.0.3) in a container, in October 2026.
Install snapd on Arch Linux
The AUR package builds snapd from source, which takes a couple of minutes because it compiles the Go daemon and the C helper snap-confine. That also means the build pulls in a Go toolchain and several other tools you may never use again, so plan for the space and clean them up afterwards. Before you start, you need:
- the
base-develgroup andgit - an AUR helper such as
yay - about 330 MiB of free space for the build tools, which
yaycan remove afterwards
If you do not have yay yet, our yay install guide builds it in one step. With the helper in place, install snapd:
yay -S --removemake snapd--removemake deletes the build-only packages (go, go-tools, xfsprogs, python-docutils and a few others, 317.72 MiB in our run) once the package is built, so they do not linger on a desktop that only needed them once. The build took 140 seconds on a 2-vCPU VM. The runtime dependencies stay installed, and they matter later:
squashfs-tools, because every snap is a SquashFS imageapparmor, whichsnapduses for confinement when the kernel has it enabledlibseccomp, for the system call filters every snap gets
Confirm the package is installed before you go further:
pacman -Q snapdpacman answers with the package name and the release it installed:
snapd 2.78-1If the install stops with “pacman is currently in use, please wait” instead, another pacman process holds the database lock, usually an update still running in another terminal or in the background. Let it finish rather than deleting the lock file. Our guide on fixing the pacman lock shows how to check which process holds it.
Install snapd on Manjaro
Manjaro packages snapd in its own extra repository, so there is nothing to compile. In our Manjaro 26.0.3 container the repository carried snapd 2.76.2-2, a little behind the AUR build, and it pulled in the same apparmor and squashfs-tools dependencies:
sudo pacman -S snapdPamac users can also add libpamac-snap-plugin, which lets the graphical package manager search and install snaps next to regular packages once you turn on snap support in Pamac’s preferences. Everything after this point is the same on both distributions, because the package ships the same systemd units and the same /etc/profile.d/snapd.sh script.
Start the snapd socket
snapd is socket-activated, so you enable the socket rather than the service. The daemon then starts the first time a snap command talks to it, and it stays out of your memory on days you do not use snaps at all:
sudo systemctl enable --now snapd.socketDo not install a snap straight after this. On a fresh install the daemon spends its first seconds seeding the system, which registers the device with the store, and a snap install sent before that finishes fails with:
error: too early for operation, device not yet seeded or device model not acknowledgedNothing is broken when you see it, so there is no need to restart anything. Wait for the seed to finish instead, which took 1 second on our VM:
sudo snap wait system seed.loadedOne more check before your first snap. Stock Arch boots without AppArmor, but some Manjaro installs already have it switched on, and then snapd needs its AppArmor unit as well or snap apps may fail to start. Ask the kernel:
aa-enabledIf it prints Yes, enable both AppArmor units now. If it prints No, skip this and come back to it in the AppArmor section below:
sudo systemctl enable --now apparmor.service snapd.apparmor.serviceThat section also covers what confinement level to expect on Arch once AppArmor is running.
Install your first snap
The first install is slow because snapd downloads its own snapd snap and the core base before the app itself. The hello-world test snap took 40 seconds here, most of it spent fetching those two:
sudo snap install hello-worldExpect a few INFO lines while it waits, then the install line and a PATH warning:
2026-10-15T18:33:36Z INFO Waiting for automatic snapd restart...
2026-10-15T18:33:37Z INFO Waiting for automatic snapd restart...
2026-10-15T18:33:38Z INFO Waiting for automatic snapd restart...
2026-10-15T18:33:39Z INFO Waiting for automatic snapd restart...
hello-world 6.4 from Canonical** installed
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not
restarted your session since you installed snapd, try doing that.
Please see https://forum.snapcraft.io/t/9469 for more details.The INFO lines are snapd swapping in the snapd snap it just downloaded, and the warning comes from the snap client checking the PATH that sudo passes it. Snap apps live in /var/lib/snapd/snap/bin, and the package already ships /etc/profile.d/snapd.sh to add that directory to PATH, but the script only runs in a new login shell. Log out and back in (or reboot), then run the test snap by name:
hello-worldThe command now resolves from PATH and prints its greeting:
Hello World!Older guides tell you to append the path to /etc/profile by hand. You do not need that line, because the profile script does the same thing and also adds /var/lib/snapd/desktop to XDG_DATA_DIRS, which is how snap desktop apps show up in your application menu. A hand-written export only fixes the shell, so desktop apps would still be missing from the menu.
Enable classic snaps with the /snap link
Some snaps, including go, code and most IDEs and compilers, use classic confinement: they run without the sandbox and expect to find themselves under /snap. Arch puts snaps under /var/lib/snapd/snap instead, so a classic install fails until you link the two:
sudo snap install --classic goOn a fresh install it refuses, because the /snap path doesn’t exist yet:
error: cannot install "go": classic confinement requires snaps under /snap or
symlink from /snap to /var/lib/snapd/snapCreate the link the error asks for, then retry the install:
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install --classic goGo installs this time. The PATH warning comes back on every sudo snap install, even after you log in again, because Arch’s sudo resets PATH to a fixed list without the snap directory. It’s harmless once your own shell has that directory:
go 1.27.1 from Canonical** installed
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not
restarted your session since you installed snapd, try doing that.
Please see https://forum.snapcraft.io/t/9469 for more details.The go snap pulled in the core24 base too, so our VM now had five snaps mounted as SquashFS loop devices. sudo du -shx /var/lib/snapd put the real cost at 281 MB, and most of it is the two bases and the snapd snap (110 MB, 70 MB and 47 MB), not the apps themselves. Each base is shared, so a second app on core24 costs far less than the first one, but a desktop with a dozen snaps on three different bases adds up quickly.
Turn on AppArmor confinement
Snaps rely on AppArmor for the file and resource rules of their sandbox, and the stock Arch kernel builds AppArmor in but leaves it off. Check which security modules are active:
cat /sys/kernel/security/lsmThe test VM’s stock kernel returned this list:
capability,landlock,lockdown,yama,bpfNo apparmor in that list means snapd reports partial confinement and can’t apply its AppArmor profiles. To turn it on, add an lsm= parameter to the kernel command line that puts apparmor back in the list. Check /etc/default/grub first: if the line already carries an lsm= or security=apparmor value, edit that one instead of adding a second. On a stock GRUB setup, prepend it to GRUB_CMDLINE_LINUX_DEFAULT and regenerate the config:
sudo sed -i 's/^GRUB_CMDLINE_LINUX_DEFAULT="/&lsm=landlock,lockdown,yama,integrity,apparmor,bpf /' /etc/default/grub
sudo grub-mkconfig -o /boot/grub/grub.cfgIf you boot with systemd-boot, add the same lsm= value to the options line of your entry under loader/entries/ on the EFI system partition instead, and if you boot a unified kernel image, put it in /etc/kernel/cmdline. The Arch Wiki kernel parameters page covers each boot loader. Then enable the AppArmor service and the snapd unit that loads the snap profiles, and reboot:
sudo systemctl enable apparmor.service snapd.apparmor.service
sudo rebootAfter the reboot the module list includes apparmor, and aa-status showed 175 profiles loaded, among them one for each snap command (snap.hello-world.hello-world, snap.go.go and so on). Confinement still reads partial, and that’s the expected result on Arch, not a failed setup. The snapd journal says why. Search it for AppArmor:
sudo journalctl -u snapd -b | grep -i apparmorOne line explains the partial result:
Oct 15 18:35:48 cfg-arch02 snapd[658]: backends.go:70: AppArmor status: apparmor is enabled but some kernel features are missing: networkFine-grained network rules for AppArmor come from a patch that Ubuntu carries in its kernel and the mainline Arch kernel doesn’t, so snapd never reports strict here. The file rules work regardless, which the hello-world.evil command proves: it tries to write outside its sandbox and gets refused. The refusal is logged as an audit event, which is where to look when a real snap misbehaves:
sudo journalctl _TRANSPORT=audit | grep DENIEDThe hello-world.evil attempt shows up as a DENIED entry naming the file it tried to create:
Oct 15 18:52:51 cfg-arch02 audit[4799]: AVC apparmor="DENIED" operation="mknod" class="file" profile="snap.hello-world.evil" name="/var/tmp/myevil.txt" pid=4799 comm="evil" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000The screenshot below shows the same test next to the confinement level and the installed snaps:
If you would rather skip AppArmor, snaps still install and run, with the seccomp filters and mount namespaces but without the file rules. For apps you would trust as a regular package anyway, that is a reasonable trade, because a pacman package gets no sandbox at all. It matters more for snaps from publishers you do not know, since the file rules are what stop an app from reading the rest of your home directory. The Arch Wiki Snap page tracks packaging changes, and the AppArmor cheat sheet covers aa-status and profile modes if you want to go further.
Manage snaps, channels and refreshes
Day to day you need only a handful of snap commands, and they work the same on Arch as on Ubuntu. These are the ones we used during the tests:
| Command | What it does |
|---|---|
snap find htop | Search the Snap Store |
snap info go | Show the publisher, channels and versions |
snap list | List installed snaps with revision and tracking channel |
sudo snap refresh | Update every snap now |
sudo snap refresh go --channel=1.26/stable | Switch a snap to another channel |
sudo snap revert go | Go back to the previous revision |
snap connections htop | Show which interfaces a snap uses |
sudo snap connect htop:mount-observe | Grant an interface that isn’t auto-connected |
sudo snap remove --purge htop | Remove a snap and skip the automatic snapshot |
Channels are where snaps differ most from pacman packages. snap info go listed a track for every Go release back to 1.6, plus FIPS builds for the newer ones, so you can pin a release line and still get its patch releases. That is the main reason to take a compiler or runtime from Snap on a rolling distribution, because pacman always moves you to the newest Go while a track keeps an older project on the release it was built with. Switching to 1.26/stable replaced Go 1.27.1 with 1.26.8 and kept the old revision on disk, which snap list --all shows.
snap list --all goThe old revision is still listed, marked disabled in the Notes column:
Name Version Rev Tracking Publisher Notes
go 1.27.1 11295 1.26/stable canonical** disabled,classic
go 1.26.8 11300 1.26/stable canonical** classicsudo snap revert go brought 1.27.1 back, but look at the Tracking column afterwards: it still said 1.26/stable. A revert changes the revision, not the channel, so the next refresh would install 1.26 again. Switch the channel back with --channel=latest/stable if the revert is meant to stick.
Snaps update themselves four times a day by default, which surprises people coming from pacman, where nothing changes until you run -Syu. To move those refreshes into a quiet window and keep fewer old revisions on disk, set the refresh timer and retention:
sudo snap set system refresh.timer=fri,02:00-04:00
sudo snap set system refresh.retain=2snap refresh --time confirms the new timer. To stop one snap from updating on its own, hold it. A plain sudo snap refresh --hold go printed General refreshes of "go" held indefinitely on our VM, and --hold=72h sets a time limit instead. A hold only blocks automatic refreshes, so a manual snap refresh go still updates the snap, and sudo snap refresh --unhold go lifts it. The snapcraft guide to managing updates lists the other refresh settings. If you’re still deciding whether a snap is the right format for an app at all, our Snap vs Flatpak vs AppImage comparison weighs the three, and the Flatpak guide covers the main alternative on Arch.
Remove snapd cleanly
Order matters here. We removed the package first on the first attempt, and its unit files disappeared while their enable links stayed behind in /etc/systemd/system. The daemon kept running as a “not-found” unit, and we had to delete the leftover links by hand. Stop and disable everything first:
sudo systemctl disable --now snapd.socket snapd.service snapd.apparmor.service apparmor.serviceDrop apparmor.service from that line if you use AppArmor for anything besides snaps, which is the case on Manjaro installs that shipped with it on.
Then remove the package. Its pre-remove hook unmounts and deletes every installed snap, so you don’t need to remove them one by one, and -ns takes the unused apparmor and squashfs-tools with it unless something else depends on them or you installed them explicitly:
sudo pacman -Rns snapdThat took 1 second with five snaps installed. Two things are left for you to delete, because neither belongs to the package: the /snap link you created and the per-user ~/snap directory that holds each snap’s settings:
sudo rm /snap
rm -rf ~/snapIf you added the lsm= parameter only for snaps, remove it from /etc/default/grub and run sudo grub-mkconfig -o /boot/grub/grub.cfg again. Our run left no snap* units, no mounts and no /var/lib/snapd once those steps were done.
Fix common snap errors on Arch
Every message below came up during our tests, and each has a one-line cause.
error: too early for operation, device not yet seeded
You ran snap install within seconds of enabling snapd.socket. Run sudo snap wait system seed.loaded and retry.
error: classic confinement requires snaps under /snap
The /snap link is missing. Create it with sudo ln -s /var/lib/snapd/snap /snap, then install the classic snap again.
Warning: /var/lib/snapd/snap/bin was not found in your $PATH
Your shell started before snapd was installed. Log out and back in so /etc/profile.d/snapd.sh runs. Until then, call apps by their full path, such as /var/lib/snapd/snap/bin/hello-world.
the snapd.apparmor service is disabled; snap applications will likely not start
snap warnings shows this when AppArmor is active in the kernel but snapd.apparmor.service isn’t enabled, so the snap profiles never load. Run sudo systemctl enable --now snapd.apparmor.service.
Confinement stays partial after enabling AppArmor
That is normal on the stock Arch kernel. snap debug confinement reports strict only when the kernel has the AppArmor network patch that Ubuntu ships, and the snapd journal names the missing feature as network. Snaps still get their file rules, seccomp filters and mount namespaces.
