You need an app that only exists as a Snap
You found a tool you need for work or a project. The developer's documentation lists only a Snap package. You run sudo snap install <app> and the terminal returns bash: snap: command not found. You search for a repository, find references to third-party sources, and pause. You know Fedora uses dnf for system packages and Flatpak for applications. You want the software, but you also want to keep your system stable and maintainable.
This article covers how to install and manage Snap packages on Fedora, why the friction exists, and how to handle the maintenance overhead that comes with running a second package ecosystem.
Why Fedora does not support Snap by default
Fedora does not ship the snapd daemon. The project actively discourages Snap usage in favor of Flatpak and native packages. This is a design decision based on system architecture and resource management.
Snap introduces a separate background daemon, a separate filesystem hierarchy, and an independent update mechanism. The snapd service runs continuously, consumes memory, and manages its own confinement model using AppArmor. Fedora relies on SELinux for system-wide security. Running Snap adds a second security layer that can complicate troubleshooting. When a Snap application misbehaves, you have to check AppArmor logs, SELinux alerts, and the Snap daemon logs. The debugging surface area doubles.
Snap packages are self-contained. They bundle their own libraries and runtime. This isolation is useful for distribution, but it increases disk usage. Each Snap package includes its own copy of dependencies. Over time, the disk footprint grows faster than with native packages that share libraries via dnf.
The update cadence also differs. dnf updates happen when you run the command or via a configured timer. Snap updates automatically in the background, independent of the system. You can end up with a new version of an application while the rest of the system is upgrading. This independence can cause version drift or break integration with host drivers.
Fedora prefers a unified experience. Flatpak integrates with the desktop environment, shares runtimes with the system where possible, and updates in a way that aligns with Fedora's philosophy. Adding Snap fragments that experience.
How to install Snap on Fedora
If you need a Snap package, you can install the daemon from the Fedora repositories. The process requires enabling the socket unit and creating a symlink so the binaries can find their runtime environment.
Here's how to install the Snap daemon and start the service.
sudo dnf install snapd # Install the snapd daemon and core libraries from the Fedora repositories
sudo systemctl enable --now snapd.socket # Enable the socket unit so snapd starts on demand and persists across reboots
sudo ln -s /var/lib/snapd/snap /snap # Create a symlink so snap binaries can locate their runtime environment
The snapd.socket unit uses socket activation. The daemon starts only when a client connects. This reduces resource usage compared to a traditional service that runs constantly. The symlink is required because Snap expects its data at /snap, but Fedora installs it under /var/lib/snapd/snap. Without the link, installed snaps will fail to execute.
Log out and log back in to ensure your shell picks up the new paths. Some desktop environments require a full session restart to recognize the snap command.
Run the symlink command. Without it, the snap binaries cannot locate the runtime libraries.
Verify the installation
Once the daemon is running, you can install packages using the snap command. Verify the service is active and the package installs correctly.
Here's how to check the daemon status and install a package.
systemctl status snapd.socket # Confirm the socket unit is active and listening for connections
sudo snap install <package-name> # Fetch and install the package from the Snap Store
snap list # Display all installed snap packages, their versions, and revision numbers
The snap list output shows the package name, version, revision, and tracking channel. If the revision column is empty or the status is not active, the installation failed. Check the journal for errors.
Check snap list before you assume the app is ready. A missing revision number means the download failed silently.
Common pitfalls and error messages
Snap on Fedora can trigger specific errors related to paths, confinement, and updates.
If you see bash: snap: command not found after installation, the symlink is missing or your shell environment hasn't refreshed. Run the symlink command again and restart your session.
bash: snap: command not found
Snap uses AppArmor for confinement. Fedora uses SELinux. Both can block access. If a Snap application cannot access your home directory or a specific device, you will see permission errors. Do not disable SELinux. The denial usually indicates a missing interface connection. Use snap connections <package-name> to check which interfaces are plugged. Use snap connect <package-name>:<interface> to grant access.
SELinux denials related to snapd appear in the journal. Read the summary before making changes.
journalctl -t setroubleshoot | grep snapd # Filter SELinux alerts related to the snapd daemon
Snap updates automatically. If you want to control when updates happen, you can check the refresh schedule or hold updates for a specific package.
Here's how to manage the update schedule and hold a package.
snap refresh --time # Show the current refresh window and last update time
snap refresh --hold <package-name> # Prevent the daemon from updating this package until the hold is removed
snap refresh --unhold <package-name> # Re-enable automatic updates for the package
Holding a package is useful when you are testing a new version or preparing for a system upgrade. Independent updates can break integration with host drivers or kernel modules.
Read the SELinux alert before disabling the policy. The denial usually points to a missing interface connection, not a broken system.
Managing updates and conflicts
Snap updates independently of dnf. This creates a maintenance gap. You might run dnf upgrade --refresh to update the system, but your Snap packages update on their own schedule. The daemon checks for updates periodically and applies them in the background.
This independence has risks. If you upgrade Fedora to a new release, the kernel and system libraries change. Snap packages are self-contained, so they usually survive the upgrade. However, if a Snap relies on a host kernel feature, a specific driver, or a hardware interface, the upgrade might break the application. The Snap might try to use a new kernel API that behaves differently, or a driver update might change the device node the Snap expects.
Hold the snap refresh during a major system upgrade. Verify the app works before letting the daemon update it.
You can also check for updates without applying them. This helps you plan maintenance windows.
snap refresh --list # Show available updates without installing them
sudo snap refresh # Apply all pending updates immediately
Use snap refresh --list to audit pending changes. If a critical update is available, apply it before you start other work.
When to use Snap versus alternatives
Choose the package format based on availability, integration needs, and maintenance preferences.
Use Snap when the developer only distributes the software as a Snap and no alternative exists. Use Flatpak when you need a desktop application with access to standard portal APIs for file access and authentication. Use DNF when you are installing system tools, libraries, or development packages that must integrate with the base OS. Stay on native Fedora packages when you want minimal resource usage and updates that align with the system release cycle.