How to uninstall a Snap package

Uninstalling a Snap package seems like a one-line job to most technicians, but snapd doesn’t fully let go of what it removes. If you don’t know what you’re doing, it quietly stashes a copy of the package’s user, system, and configuration data in an automatic snapshot and holds onto it for 31 days before deleting it on its own.

So the workstations you thought were clean could actually be still carrying a month of leftover data, or a “simple” removal turns out to be a base Snap that other applications depend on.

So here’s everything you need to know to make sure you’re doing it properly across all the workstations in your fleet.

What to check before uninstalling a snap package

Before you remove anything, take a quick look at what’s installed, what permissions the removal will require, and what actually happens to the data afterward.

Production systems tend to accumulate more Snap packages than admins expect, including base Snaps that other applications quietly rely on. Here’s how you check the full list:

1. Run snap list to see every installed package along with its version, revision, publisher, and tracking channel

2. Run snap info <package-name> for any package you’re planning to remove, to confirm its available channels and current tracking status

   

The tracking channel (latest/stable, latest/edge, etc.) tells you which release stream a package follows. Reviewing it before removal is a small step, but it’s the difference between confidently uninstalling the right application and accidentally taking out a base Snap that something else depends on.

» Did you know you can rename a directory on Linux?

Confirm you have the right permissions and a clear system state

Removing a Snap package requires root privileges, which is why the command runs with sudo. A standard user can view what’s installed with snap list, but the removal itself modifies system-managed directories and will fail without elevated access.

Beyond permissions, the package can’t be locked by another Snap operation, such as an install, refresh, or rollback already underway, and the snapd service needs to be running since it manages every Snap lifecycle action.

In practice, permission errors are less common than removals blocked by an in-progress operation, so it’s worth confirming nothing else is actively touching the package before you retry. On production systems, it’s also worth a quick check that no scheduled jobs, automations, or active users are depending on the application before it comes out from under them.

» Here’s how to change file permissions on Linux and fix the permission denied error

5 ways to uninstall Snap packages

Once you’ve confirmed what’s installed and what depends on it, just pick the right method below for the situation, whether it’s a quick command-line removal, a full data wipe with --purge, a graphical option for desktop users, cleanup of old revisions, or a scripted removal across an entire fleet.

Note: Every method below assumes you already have sudo access.

Method 1: Remove a package from the command line

This is the standard method for most removals, whether you’re clearing out one unused application or working through a short list on a single machine.

1. Confirm the exact package name with snap list

2. Run sudo snap remove <package-name> to remove it

   For example, sudo snap remove vlc stops the application, unmounts its runtime files, updates the Snap package database, and creates an automatic data snapshot unless you specify otherwise.

3. Re-run snap list afterward to confirm the package no longer appears, or run snap saved to check what snapshot was retained

   

Method 2: Permanently delete a package’s data with –purge

Use this method when you’re certain you won’t need to restore the application later, since it skips the recovery snapshot entirely. This fits lab environments, temporary VMs, or software that’s being permanently retired more than production systems you might need to roll back.

Run sudo snap remove --purge <package-name> to remove the package and its data in one step

For example, sudo snap remove --purge firefox deletes the application’s associated user and system data immediately, rather than creating the 31-day recovery snapshot a standard removal would.

Once this runs, there’s no snapshot to restore from, so it’s worth confirming beforehand that the package’s configuration and data genuinely aren’t needed.

Method 3: Remove a package through a graphical interface

This method suits individual workstations and desktop users who’d rather avoid the terminal. It triggers the same underlying removal process as the CLI, just through a visual interface.

1. Open your Linux version software; for example, Ubuntu Software
2. Select the Installed tab
3. Locate the Snap application you want to remove
4. Click Uninstall

5. Enter your administrator password if prompted to authenticate

   

Once the removal completes, refresh the Installed list or search for the package to confirm it’s gone. For server environments or large-scale administration, the command line is the better fit, since it integrates more naturally with scripting and change management processes.

Method 4: Clean up disabled revisions to free up space

Snap keeps previous revisions around after an update so you can roll back if needed, and over time those inactive revisions add up. Use this method for routine housekeeping once you’re confident a recent update is stable, not as part of removing a package outright.

1. Run snap list --all to see every revision, including disabled ones
2. Confirm which revisions are marked disabled in the output
3. Run sudo snap remove <package> --revision=<revision> to remove a specific inactive revision

For example, sudo snap remove firefox --revision=5321 removes only that inactive revision while leaving the currently installed version untouched. It’s worth waiting until the updated revision has been running successfully for a while before clearing out the old one, so you don’t lose the rollback option too early.

Method 5: Remove snap packages across multiple machines at once

For fleets of any real size, removing packages one machine at a time doesn’t scale. This method fits situations where the same package needs to come off many endpoints at once, with consistent execution and a record of what happened on each one.

1. Write or adapt a Bash script that loops through installed packages and runs snap remove on each target
2. Test the script on a small pilot group of machines first
3. Confirm no business-critical applications on those machines depend on the packages being removed

4. Deploy the script across the remaining fleet in stages, reviewing execution results as you go

   

Don’t know how to write a complex Bash script like that? No worries. Atera’s AI Copilot can write it for you from simple queries. Then you can deploy that same removal script remotely across selected devices or device groups on demand using Atera’s RMM platform without needing to touch each machine individually.

» Here’s how to install Atera’s Linux Agent and monitor Linux servers at scale

Troubleshooting and advanced removal methods

If your organization decides they don’t want to use any Snap packages anymore, you can get rid of Snap support altogether. Use this method only when you’re certain Snap won’t be needed on the machine going forward, since it removes the daemon that manages every Snap operation, not just an individual package.

1. Uninstall any remaining Snap applications first, to avoid leaving orphaned packages or data behind
2. Run sudo systemctl disable --now snapd.service to stop and disable the service
3. Run sudo apt purge snapd to remove the daemon and its supporting files

4. Run systemctl status snapd to confirm the service is no longer found

   

Once snapd is gone, Snap packages can’t be installed, updated, or managed until it’s reinstalled, though that’s a fully reversible step through your distribution’s package manager whenever Snap support is needed again.

How to resolve a “Snap is in use” or “process running” error

A Snap package can’t be removed while it’s actively running, so this error means something needs to stop before the removal can proceed. To fix it:

1. Run ps -ef | grep <package> or snap services to identify the running process or service
2. Stop the application, or run snap.<snapname>.<app>.service if it runs as a systemd service

3. Re-run the snap remove command

   

Resolve a dependency error when removing a core snap

Core Snaps like core18, core20, and core22 provide shared runtime libraries that other applications rely on, so Snap blocks their removal while dependents still exist rather than risking a broken environment.

1. check snap info on your installed snaps to see which ones declare this base.
2. Remove or migrate those dependent applications first

3. Re-run sudo snap remove <core-snap> once no remaining Snaps depend on it

   

Forcing this removal isn’t worth the risk if it’s not necessary, since it can prevent every dependent application from starting correctly afterward. It’s better to treat it as a small maintenance task. Then confirm what’s still relying on the core Snap, clear or update those dependencies on your own schedule, and only remove the core package once nothing needs it anymore.

Make snap cleanup part of routine maintenance

None of this is complicated once you know where the friction points sit. Check what’s installed and what depends on it, understand what gets left behind, and choose --purge or the default snapshot based on whether you might need to roll back.

Doing it at scale is usually where manual habits break down. Atera’s remote scripting lets IT teams and MSPs push a tested removal script across selected devices or device groups on demand, so a cleanup that would otherwise mean an afternoon of individual SSH sessions runs the same way, with the same safeguards, everywhere it needs to.

» Get started with Atera for free