Snap ist ein universelles Paketformat von Canonical, das auf nahezu jeder Linux-Distribution funktioniert. Ein Snap-Paket bündelt eine Anwendung samt ihrer Abhängigkeiten in einem komprimierten SquashFS-Image und läuft in einer Sandbox, die den Zugriff auf Ressourcen klar regelt. Auf Ubuntu ist Snap Standard, auf Fedora und Arch lässt es sich nachrüsten.

01 · Abschnitt

Was Snap ist

Snap wurde ursprünglich für Ubuntu Core entwickelt — eine minimale, transaktionale Ubuntu-Variante für IoT-Geräte — und später auf Desktop und Server ausgeweitet. Im Gegensatz zu klassischen Paketen wie .deb oder .rpm ist ein Snap nicht in das Dateisystem entpackt, sondern bleibt als Image erhalten und wird zur Laufzeit gemountet.

Ein Snap-Paket enthält:

  • Die ausführbare Anwendung mit allen benötigten Bibliotheken
  • Eine snap.yaml mit Metadaten und Berechtigungen
  • Optional Hooks für Installation, Update und Konfiguration
  • Eine Signatur, die vom Snap Store geprüft wird

Da alle Abhängigkeiten mitgeliefert werden, läuft derselbe Snap auf Ubuntu, Debian, Fedora, Arch, openSUSE und Manjaro — vorausgesetzt, der Daemon snapd ist installiert. Diese Distro-Unabhängigkeit ist Snaps Hauptargument gegenüber apt, dnf und pacman.

02 · Abschnitt

snapd — der Daemon im Hintergrund

snapd ist der Hintergrunddienst, der Snaps verwaltet: Er lädt Pakete aus dem Snap Store, mountet die SquashFS-Images, verwaltet die Sandbox-Profile und kümmert sich um automatische Updates.

Distributionsnapd-Status
UbuntuVorinstalliert, Standard-Paketformat für viele Apps
DebianÜber apt install snapd nachrüstbar
FedoraÜber dnf install snapd plus Symlink
Arch LinuxÜber AUR (snapd-Paket)
openSUSEÜber zypper install snapd
Linux Mint, Pop!_OSStandardmäßig deaktiviert (Distro-Politik)

Den Status prüfst du mit systemctl status snapd. Auf Distributionen ohne native Integration muss der Service nach der Installation aktiviert werden (sudo systemctl enable --now snapd.socket).

03 · Abschnitt

Channels — Stable, Beta, Edge

Snaps werden in Channels ausgeliefert. Ein Channel ist eine Veröffentlichungsschiene, die unterschiedliche Reifegrade einer Anwendung anbietet. Standardmäßig wird aus dem stable-Channel installiert.

ChannelBedeutung
stableProduktionsreife Version, gründlich getestet
candidateRelease-Kandidat, kurz vor stable
betaVorabversion mit neuen Features, weniger getestet
edgeTagesaktuelle Builds aus dem Hauptzweig, instabil möglich

Den Channel wählst du beim Installieren oder wechselst ihn nachträglich.

Bash Channel beim Installieren wählen 
sudo snap install code --classic --channel=edge
Bash Channel später wechseln 
sudo snap refresh code --channel=stable
04 · Abschnitt

Wichtige Befehle

Die meisten Snap-Befehle ähneln denen anderer Paketmanager. Schreibende Operationen brauchen sudo, Lesezugriffe wie list und info nicht.

BefehlBedeutung
sudo snap install <name>Snap installieren
sudo snap remove <name>Snap entfernen
sudo snap refreshAlle Snaps aktualisieren
snap listInstallierte Snaps auflisten
snap find <begriff>Snap Store durchsuchen
snap info <name>Detailinformationen zu einem Snap
sudo snap revert <name>Auf vorherige Version zurückrollen
snap connections [name]Sandbox-Verbindungen anzeigen
snap servicesSnap-eigene Dienste auflisten
snap logs <name>Logs eines Snaps ansehen
05 · Abschnitt

Auto-Updates

Snaps aktualisieren sich automatisch im Hintergrund — typischerweise vier Mal pro Tag. Im Gegensatz zu apt oder dnf musst du also nichts manuell anstossen, das System hält Apps von selbst aktuell. Das ist gleichzeitig Stärke und Schwäche: Sicherheitsupdates kommen ohne Zutun, aber laufende Apps können in unpassenden Momenten zum Neustart aufgefordert werden.

Mit snap refresh --hold lässt sich der Auto-Update-Mechanismus pausieren.

Bash Updates für 24 Stunden pausieren 
sudo snap refresh --hold=24h
Bash Updates dauerhaft pausieren (max. 60 Tage) 
sudo snap refresh --hold

Auch zeitgesteuerte Refresh-Fenster sind möglich — sudo snap set system refresh.timer=03:00-05:00 legt fest, dass Updates nur nachts laufen.

06 · Abschnitt

Sandboxing und Interfaces

Jeder Snap läuft in einer Sandbox, die mit AppArmor, seccomp und Cgroups durchgesetzt wird. Das bedeutet: Eine Snap-Anwendung kann standardmäßig nicht beliebig auf das Dateisystem, das Netzwerk oder Hardware zugreifen — sie muss explizit Berechtigungen anfordern.

Diese Berechtigungen heißen bei Snap Interfaces. Bekannte Interfaces sind:

InterfaceWas es erlaubt
homeLese-/Schreibzugriff auf ~
networkAusgehende Netzwerkverbindungen
network-bindLokale Ports binden
removable-mediaZugriff auf USB-Sticks und externe Laufwerke
audio-recordMikrofon-Zugriff
cameraKamera-Zugriff
system-observeProzessliste lesen

Welche Interfaces ein Snap angefragt und welche tatsächlich verbunden sind, zeigt snap connections. Mit snap connect lassen sich Interfaces manuell verbinden, mit snap disconnect wieder trennen.

Bash Interfaces eines Snaps anzeigen 
snap connections code
Bash Interface manuell verbinden 
sudo snap connect code:removable-media
07 · Abschnitt

Mounted /snap und Performance

Snaps werden nicht entpackt, sondern als SquashFS-Images unter /var/lib/snapd/snaps/ abgelegt. Beim Start mountet snapd jedes Image als Loop-Device unter /snap/<name>/<revision>/. Daraus ergibt sich eine charakteristische Eigenheit: df -h zeigt für jeden installierten Snap einen eigenen Mount-Eintrag, was die Ausgabe schnell unübersichtlich macht.

Der erste Start eines Snaps ist spürbar langsamer als der einer nativ installierten Anwendung — das SquashFS-Image muss gemountet und dekomprimiert werden, AppArmor-Profile werden geladen, der Sandbox-Kontext wird vorbereitet. Folgestarts sind dank Caching deutlich schneller, erreichen aber selten die Geschwindigkeit nativer Pakete.

Pro Snap werden zudem alte Revisionen vorgehalten, um snap revert zu ermöglichen. Standardmässig sind das zwei Revisionen — wer Speicherplatz sparen will, reduziert das mit sudo snap set system refresh.retain=2.

08 · Abschnitt

Praxis-Patterns

Suchen und installieren

Bash 
snap find code
sudo snap install code --classic

snap find durchsucht den Snap Store nach Stichwörtern und zeigt passende Pakete mit Channel und Beschreibung. Anschließend installiert snap install das gewünschte Paket — hier mit --classic, weil VS Code außerhalb der Sandbox laufen muss.

Klassisches Confinement

Bash 
sudo snap install code --classic

Manche Anwendungen — typischerweise IDEs, Code-Editoren oder Compiler — funktionieren nicht innerhalb der strengen Sandbox, weil sie auf das gesamte Dateisystem, externe Toolchains oder Debugger zugreifen müssen. Mit --classic läuft der Snap außerhalb der Sandbox mit normalen User-Rechten. Das ist bequem, hebt aber den Sicherheitsvorteil von Snap weitgehend auf.

Channel wechseln

Bash 
sudo snap refresh code --channel=edge

Damit wechselt ein bereits installierter Snap auf einen anderen Channel — hier von stable auf edge, um die neuesten Vorabversionen zu testen. Der Wechsel ist jederzeit reversibel, bleibt der Wechsel auf stable aus, kann der Snap jedoch nicht „downgegradet” werden, wenn die edge-Version Daten in einem neueren Format gespeichert hat.

Auto-Update für ein einzelnes Paket pausieren

Bash 
sudo snap refresh --hold=24h code

Hält Auto-Updates speziell für den Snap code für 24 Stunden zurück. Praktisch vor wichtigen Demos, Präsentationen oder wenn ein neues Release erst getestet werden soll, bevor es einrastet.

Snap-Logs verfolgen

Bash 
snap logs code -f

Zeigt die Logs des Snaps und folgt neuen Einträgen (-f wie bei tail). Snap-Logs werden über journald verwaltet, aber der snap logs-Wrapper filtert direkt auf den richtigen Snap-Kontext.

Updates manuell anstossen

Bash 
sudo snap refresh

Erzwingt eine sofortige Update-Prüfung und installiert verfügbare Updates für alle Snaps. Nützlich, wenn du nicht auf den nächsten Auto-Refresh warten willst — etwa nach einem bekannt gewordenen Sicherheitsupdate.

09 · Abschnitt

Wissenswertes

--classic umgeht die Sandbox — Sicherheitsvorteil weg.

Snaps mit —classic laufen außerhalb der AppArmor-/seccomp-Sandbox und haben damit dieselben Rechte wie der ausführende Benutzer. Bei IDEs wie VS Code oder PyCharm ist das technisch notwendig, weil sie auf das gesamte Dateisystem und externe Toolchains zugreifen müssen. Aber: Du verzichtest damit auf das Hauptverkaufsargument von Snap. Verwende —classic nur bei vertrauenswürdigen Anwendungen aus dem offiziellen Snap Store und prüfe vor der Installation in snap info, ob ein Snap wirklich klassisches Confinement braucht.

Auto-Updates können Apps in unpassenden Momenten neu starten.

Snaps aktualisieren sich automatisch — bis zu vier Mal pro Tag. Das hält das System sicher, kann aber laufende Anwendungen mitten in der Arbeit zum Neustart bewegen, sobald ein Update bereitsteht. Besonders bei Browsern, Editoren oder Konferenz-Tools kann das stören. Mit sudo snap refresh —hold pausierst du Auto-Updates für maximal 60 Tage, mit refresh.timer legst du feste Wartungsfenster fest. Auf Servern und in produktiven Umgebungen ist eine bewusste Update-Strategie Pflicht.

df -h zeigt einen Loop-Mount pro Snap — kosmetisch nervig.

Jeder installierte Snap erscheint als eigener Loop-Mount im Output von df -h und mount. Bei zwanzig installierten Snaps werden das schnell zwanzig Zeilen — die Ausgabe wird unübersichtlich, obwohl die Snap-Mounts technisch keinen zusätzlichen Speicher belegen (sie zeigen auf das SquashFS-Image). Filtere mit df -h -x squashfs, um Snap-Mounts auszublenden, oder verwende df -hT —type=ext4 —type=xfs für einen klareren Blick auf die echten Dateisysteme.

Snap auf Fedora und Arch braucht manuelle Schritte.

Auf Fedora installierst du Snap mit sudo dnf install snapd und musst danach den Symlink sudo ln -s /var/lib/snapd/snap /snap setzen, damit klassische Snaps korrekt funktionieren. Auf Arch Linux liegt snapd im AUR und muss über einen AUR-Helper wie yay oder manuell mit makepkg gebaut werden. Anschließend ist sudo systemctl enable —now snapd.socket nötig, damit der Daemon startet.

Snap und Flatpak parallel — funktioniert, aber doppelter Overhead.

Snap und Flatpak schließen sich technisch nicht aus, beide Daemons können nebeneinander laufen. In der Praxis bedeutet das aber: doppelte Bibliotheken, doppelte Update-Mechanismen, doppelter Plattenplatz. Wer beides braucht, lebt damit; wer flexibel ist, sollte sich für eines entscheiden. Eine pragmatische Faustregel: Snap für Apps von Canonical und für Server-Software, Flatpak für GUI-Desktop-Anwendungen.

Mint und Pop!_OS deaktivieren Snap — Distro-Politik.

Linux Mint blockiert snapd aktiv per APT-Pinning, weil das Mint-Team das Konzept des proprietären Snap Stores ablehnt. Auf Pop!_OS ist Snap zwar nicht blockiert, aber System76 setzt konsequent auf Flatpak und liefert snapd nicht mit. Wer auf diesen Distros Snap nutzen will, muss das Pinning manuell entfernen oder snapd nachrüsten — und wird dabei vom Distro-Hersteller weder unterstützt noch empfohlen.

snap revert ist eine echte Stärke.

Wenn nach einem Auto-Update eine App nicht mehr läuft oder sich anders verhält, rollt sudo snap revert <name> auf die vorherige Revision zurück — ohne Reinstall, ohne Datenverlust. Das ist ein klarer Vorteil gegenüber apt oder dnf, wo ein Downgrade meist nur über das manuelle Vorhalten alter Pakete möglich ist. Snaps behalten standardmässig zwei alte Revisionen vor; mit refresh.retain lässt sich diese Zahl anpassen.

snap connect manchmal nach Install nötig.

Nicht alle Interfaces werden bei der Installation automatisch verbunden. Insbesondere sicherheitsrelevante Interfaces wie removable-media, camera oder audio-record bleiben oft getrennt und müssen mit sudo snap connect <snap>:<interface> manuell aktiviert werden. Wenn ein Snap also keinen Zugriff auf USB-Sticks oder das Mikrofon hat, lohnt ein Blick in snap connections, bevor du in der App selbst nach Bugs suchst.

Erststart langsamer als bei nativen Paketen.

Beim ersten Start eines Snaps muss snapd das SquashFS-Image mounten, AppArmor-Profile laden und die Sandbox vorbereiten — das kostet ein paar Sekunden mehr als ein nativer .deb- oder .rpm-Aufruf. Folgestarts sind durch Caching deutlich schneller, erreichen aber selten ganz die Geschwindigkeit nativer Pakete. Bei häufig genutzten Tools wie htop oder tree lohnt sich Snap deshalb selten — bei grossen GUI-Anwendungen fällt der Overhead nicht mehr ins Gewicht.

Server-Snaps wie nextcloud-snap haben eigene Konventionen.

Server-orientierte Snaps wie nextcloud, rocketchat-server oder certbot legen ihre Daten unter /var/snap/<name>/ ab — nicht unter den klassischen FHS-Pfaden. Konfiguration, Backups und Logs liegen dadurch an anderer Stelle als bei nativen Installationen. Vor dem Einsatz auf einem Produktionsserver lohnt sich ein Blick in die jeweilige Snap-Dokumentation, um die Pfade und Backup-Strategie zu verstehen.

10 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Pakete

Zur Übersicht