Snap ships enabled by default on recent Ubuntu releases. It offers a distribution-independent application format, automatic updates, dependency isolation, and optional sandboxing.

Those features are useful, but not every system needs a second package-management stack alongside APT. Desktop users may prefer traditional Debian packages, and administrators of minimal servers may want fewer background services with all software under APT-based change control.

This guide covers how to:

• Remove all installed Snap packages
• Purge the snapd service and its remaining data
• Prevent APT from reinstalling snapd
• Restore Snap later if needed

The procedure targets recent Ubuntu Desktop and Server releases, including 22.04, 24.04, and 26.04. Package selections may differ between releases.

Warning: Removing Snap also removes applications installed as snaps. Review the installed package list and back up any important application data before continuing.

Understanding Snap

Benefits and Drawbacks

Snap provides several useful features:

• Applications bundle their dependencies and run across different Linux distributions.
• Automatic updates deliver security fixes without manual intervention.
• Application confinement can restrict access to files, devices, and system resources.
• Previous revisions are retained for rollback.

These come with trade-offs:

• Slower startup: Snap applications may launch more slowly than native Debian packages, especially after boot or with a cold filesystem cache.
• Extra background services: Snap depends on the snapd daemon, systemd units, sockets, and scheduled refresh tasks.
• Higher disk usage: Applications bundle their dependencies, and older revisions are kept for rollback.
• Extra mount points: Every installed revision is mounted as a read-only SquashFS filesystem, cluttering tools such as mount, findmnt, and lsblk.
• Less predictable updates: Automatic refreshes run separately from APT upgrades and may not fit controlled maintenance windows.
• Desktop integration issues: Sandboxing can interfere with themes, browser extensions, removable drives, and access to non-standard filesystem locations.
• A second package stack: Administrators must maintain Snap in addition to APT.

The performance impact should not be overstated. Snap does not necessarily make an application slower once it has started; the common concern is launch latency from compressed contents, cold caches, and confinement setup.

For users who rely on Snap-only applications, the added infrastructure may be justified. For minimal servers or systems managed entirely through APT, snapd often provides little value while adding services, storage, mounts, and complexity.

Snap vs. AppImage

Snap and AppImage both bundle applications with most of their dependencies, but their goals differ. AppImage is a portable, self-contained executable that runs without a package manager or background service. Snap is a full software-management platform that adds automatic updates, rollback, system integration, and confinement through snapd. Users who value simplicity and direct control may prefer AppImage; Snap suits centrally managed applications that need integrated updates and sandboxing.

Removing Snap

1. Inspect the Existing Snap Installation

List the installed snaps before removing anything:

snap list

A typical desktop system may contain application snaps, shared runtimes, desktop themes, base snaps, and the snapd snap itself.

Check for saved snapshots as well:

snap saved

Removing an application with snap remove --purge skips the automatic snapshot, but existing snapshots are left in place. (Snapcraft) Application data may also exist under directories such as:

~/snap/
/var/snap/
/root/snap/

Copy anything important before proceeding.

2. Remove All Installed Snaps

Snap packages can depend on base snaps and shared runtimes, so removing every package in a single pass may fail while a base snap is still in use.

The following script makes multiple passes. Dependency failures during an early pass are expected; the script retries the remaining packages after their dependents are gone.

# Remove snaps repeatedly until none are left.
# Base snaps fail until their dependents are gone, so we loop;
# if a full pass removes nothing, we stop instead of spinning forever.
while true; do
    snaps=$(snap list 2>/dev/null | awk 'NR>1 {print $1}')
    [ -z "$snaps" ] && { echo "No snaps remain."; break; }

    removed=0
    for snap in $snaps; do
        sudo snap remove --purge "$snap" && removed=1
    done

    [ "$removed" -eq 0 ] && {
        echo "Could not remove: $snaps"
        echo "Resolve their dependencies manually and retry."
        break
    }
done

Confirm that no snaps remain:

snap list

Snap’s official decommissioning procedure requires ordinary snaps to be removed before the snapd snap itself, and --purge avoids creating automatic removal snapshots. (Snapcraft)

3. Purge the Snap Daemon

Stop the remaining Snap services and purge the Debian package that provides snapd:

sudo systemctl disable --now snapd.socket snapd.service 2>/dev/null || true
sudo systemctl disable --now snapd.seeded.service 2>/dev/null || true

sudo apt purge -y snapd
sudo apt autoremove --purge -y

Purging the snapd package removes the principal system directories, including /snap, /var/snap, /var/lib/snapd, and /var/cache/snapd. (Snapcraft) Remove any per-user data that is no longer needed:

rm -rf "${HOME}/snap" "${HOME}/.snap"
sudo rm -rf /root/snap /root/.snap

Clean up directories left behind by an interrupted or older installation:

sudo rm -rf /var/snap /var/lib/snapd /var/cache/snapd /snap

Verify that the command and systemd units are gone:

command -v snap || echo "The snap command is no longer installed."
systemctl status snapd.socket

The second command should report that the unit does not exist.

4. Prevent APT from Reinstalling Snap

Some Ubuntu packages recommend or depend on snapd. An APT preference can assign every version of snapd a negative priority, blocking normal dependency resolution from installing it again.

Create the preference file:

sudo tee /etc/apt/preferences.d/no-snapd.pref >/dev/null <<'EOF'
Package: snapd
Pin: version *
Pin-Priority: -10
EOF

Refresh the package metadata and inspect the result:

sudo apt update
apt-cache policy snapd

On a correctly pinned system, snapd should have no installable candidate, or its versions should show a negative priority.

Test the rule without changing the system:

sudo apt install --simulate snapd

APT should report that snapd cannot be installed.

Some Ubuntu metapackages or applications require snapd and cannot be installed while this preference is active. Review APT’s proposed changes carefully during future upgrades.

Restoring Snap

To make Snap available again, remove the APT preference and reinstall snapd:

sudo rm -f /etc/apt/preferences.d/no-snapd.pref
sudo apt update
sudo apt install -y snapd
sudo systemctl enable --now snapd.socket
sudo reboot

After rebooting, verify the installation:

snap version

Applications can then be installed again as usual:

sudo snap install <package-name>

Conclusion

Snap offers real benefits: portable packaging, application confinement, automated updates, rollback, and direct upstream distribution. It also introduces an extra daemon, repository, update mechanism, set of mounted filesystems, and package-management workflow.

Base the decision on the workload. Keeping Snap is reasonable when its application catalog, sandboxing, or update model is useful. Removing it is equally reasonable when APT already satisfies every software and operational requirement.