How to Fix “Failed to Set Up Mount Namespaces” Snap Error in Ubuntu

The error message “cannot update snap namespace: cannot set up snap namespace: failed to set up mount namespaces: cannot mount /var/lib/snapd/snaps/…” (frequently citing snap-confine has elevated permissions and is not confined or permission denied) occurs in Ubuntu Linux when Canonical’s snapd sandboxing container engine fails to construct an isolated filesystem mount namespace for a Snap package. Because Snaps rely on strict Linux kernel namespaces and AppArmor security confinement to isolate applications from the host operating system, any conflict in AppArmor profiles, stale mount binds, or desynchronised kernel headers halts application launch. Resolving this issue involves reloading AppArmor profiles, clearing orphaned snap mount namespaces, and updating snapd.

Understanding Why Snap Mount Namespaces Fail

When you launch a Snap application (such as Chromium, Spotify, or VS Code), the snap-confine utility initializes a private Linux mount namespace. It mounts read-only SquashFS images into /snap, overlays user directories, and enforces mandatory access control policies via AppArmor. If the running Linux kernel lacks support for user namespaces, or if AppArmor rejects the snap-confine binary’s execution profile, the sandbox setup aborts immediately.

Common technical reasons for namespace failures include:

• AppArmor Profile Desynchronisation: After upgrading Ubuntu releases or installing a new kernel, the cached AppArmor profiles in /etc/apparmor.d/ fail to match the active snap-confine binary.
• Orphaned Mount Namespace Files: Lingering runtime mount files in /run/snapd/ns/ preventing snapd from binding new container directories. For related boot module failures, see our guide on fixing failed to start Load Kernel Modules in Ubuntu.
• Non-Standard Home Directory Paths: Running user accounts located outside standard /home/username paths (e.g., /data/home or network-mounted NFS profiles), which default AppArmor rules reject. (Check our guide on fixing unable to locate package error in Ubuntu).
• Corrupted Snap Core Runtimes: Corrupted downloads of the foundational core20, core22, or core24 base runtimes.

Component	Role in Snap Execution	Failure Condition
snap-confine	Elevated helper creating sandbox environment	Unconfined execution or permission denied by kernel
AppArmor	Enforces mandatory access control restrictions	Profile parser errors reject namespace creation
Linux Kernel Namespaces	Isolates process trees and mount tables	User namespaces disabled via sysctl
/run/snapd/ns/	Stores active namespace file descriptors	Stale locked namespace files after system crash

Step 1: Reload AppArmor Profiles

Mismatched or unloaded AppArmor security profiles represent the single most common cause of snap-confine namespace rejections.

1. Open your terminal by pressing Ctrl + Alt + T.
2. Reload all registered AppArmor profiles to ensure clean kernel binding:

sudo systemctl reload apparmor.service

3. Verify that the snap-confine profile is loaded in enforcing mode:

sudo apparmor_status | grep snap-confine

4. If the output confirms the profile is active, attempt to launch your Snap application again.

Step 2: Purge Stale Namespace Run Files in /run/snapd/ns/

If an application crashed or the system shut down improperly, orphaned namespace sockets stored in volatile memory can block new sandbox instantiation.

1. In the terminal, unmount any stuck snap namespace mounts:

sudo umount -l /run/snapd/ns/*.mnt 2>/dev/null

2. Remove the lingering namespace descriptor files:

sudo rm -rf /run/snapd/ns/*

3. Restart the snapd background daemon:

sudo systemctl restart snapd.service

Step 3: Verify and Enable User Namespaces via sysctl

Some custom kernels or security hardening scripts disable unprivileged user namespaces, which breaks modern Snap sandboxing.

1. Check if unprivileged user namespaces are enabled:

cat /proc/sys/kernel/unprivileged_userns_clone

2. If the output returns 0, user namespaces are disabled. Enable them immediately:

sudo sysctl -w kernel.unprivileged_userns_clone=1

3. To make this change permanent across reboots, add the directive to sysctl:

echo "kernel.unprivileged_userns_clone=1" | sudo tee -a /etc/sysctl.d/99-snapd.conf
sudo sysctl --system

Step 4: Refresh and Reinstall the Base Snap Core Runtime

If the error specifically cites a base runtime (such as core20 or core22), reinstalling the core runtime repairs corrupted filesystem layers.

1. Update all installed Snap packages to their latest revisions:

sudo snap refresh

2. If an individual package continues to fail, reinstall its underlying base image:

sudo snap refresh core22 --edge
sudo snap refresh core22 --stable

3. If the application itself is corrupted, remove and reinstall it cleanly:

sudo snap remove --purge <package_name>
sudo snap install <package_name>

Step 5: Reinstall the snapd Package via APT

If binary permissions on /usr/lib/snapd/snap-confine were altered by system maintenance scripts, reinstalling snapd restores original permissions.

1. Reinstall snapd using Ubuntu’s package manager:

sudo apt update
sudo apt install --reinstall snapd

2. Reboot your system:

sudo reboot

Upon restart, the system will initialize pristine mount namespaces, allowing all Snap packages to launch smoothly without permission or mount errors.