This should be covered by snapshots already. When you remove a snap with snap remove foo it automatically creates a snapshot of snap data found under /var/snap and under users’ homes. (not to be confused with snap remove --purge which does not save a snapshot).
maciek@galeon:~ snap saved
Set Snap Age Version Rev Size Notes
312 test-snapd-zfsutils 13.8d 2.2.2 x1 253B auto
maciek@galeon:~ snap remove wormhole
wormhole removed
maciek@galeon:~ snap saved
Set Snap Age Version Rev Size Notes
312 test-snapd-zfsutils 13.8d 2.2.2 x1 253B auto
313 wormhole 2.32s 0.16.0+2.g1bd72f3 509 324B auto
where the content of the snapshot for wormhole is:
I was using the VS Code snap, and realised that uv tool list wouldn’t show any of my installed tools, plus uv tool install would install them in some “weird” directory that was not in the $PATH.
I then proceeded to sudo snap remove code and getting this error:
error: cannot perform the following tasks:
- Save data of snap "code" in automatic snapshot set #3 (cannot create archive:
tar: 198/.local/share/containers/storage/overlay/cf4bbf00f26d594989e57afbbfabb2ce635cf38a349ec586c347fac367126410/diff/var/lib/apt/lists/partial: Cannot open: Permission denied
tar: 198/.local/share/containers/storage/overlay/cf4bbf00f26d594989e57afbbfabb2ce635cf38a349ec586c347fac367126410/diff/var/cache/apt/archives/partial: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors)
This is with a 2-days old, freshly installed Linux Mint… I haven’t had time to screw up my system so badly yet!
Thanks for posting, though I think your issue is outside of the scope of what I’m trying to achieve here.
In any case, having a quick look at the logs, it seems that inside “code” per-snap-revision data directory you have some additional unexpected data, likely owned by podman/docker. In any case, the permissions or ownership of those files is likely an issue. When you remove a snap, by default, snapd attempts to take a snapshot of the snap’s data such that you’re later able to recover/export it, but if the data is not accessible for root (like it is in your case), creating snapshot will fail. Try snap remove --purge code, which will simply remove the snap’s data, without trying to save a snapshot.
it’s perhaps worth trying to figure out why you even have this data there? It feels wasteful to not use a dedicated, shared between revisions, snap data directory. Then again, snapd can’t really do anything about questionable packaging.
Played with a couple of variants, a single snap installation (ohmygiraffe, which pulls in gnome runtime):
https://asciinema.org/a/urVbYfMhFLm3o34Dz2zivz28v
and then a multi snap installation (ohmygiraffe + firefox + dependencies):
https://asciinema.org/a/zR0jmK2i2ycca7bPVxXTii4tM
I feels a bit better, in the sense that one can see that something is going on, but at the same time one could argue it feels a jumpy?
The first example looks brilliant; I agree the second is a bit jumpy, but it’s still better than the current version because it’s directly showing what the bottleneck actually is and it’s rewriting the same line rather than spamming the output so even though it’s jumpy, it’s not noisy.
You’re downloading the Gnome content snap in the second version at 35MB or 280Mbit per second (That’s ignoring the Firefox snap which peaks at nearly a gigabit per second too!), that’s a top end speed where we might find people in rural areas operating at 1% if not lower than that, so even with it being a bit jumpy, it’s clearly demonstrating stuff is happening, it’s just slow; rather than the current approach where you see “automatically connecting plugs” potentially 5 minutes sometimes but 10 seconds other times, when the actual interface connections are only seconds; a user not seeing the other downloads could just hit control-c thinking it’s crashed.
Perfect is the enemy of good enough, and that to me looks perfect for one and good enough in the other.
I think it would be great if snap version command also included the Revision and perhaps the current track of snapd snap.
This way, it would be easier to try to reproduce some problems (e.g., Nowadays, on the docker snap form for bug report, we ask for snap list snapd instead of snap version because of that.)
it would also be good for snap version to show the repository type from which it was installed if it wasnt installed via snapd (e.g. dpkg vs snap).
This might also make sense for other programs; e.g. snaps
In the past one would usually expect one version or one possible source type for a program.
For snaps the install/management tools and the runtime expectations differ from the programs installed via the package managers. Maybe a best practice/suggestion for version strings in snaps would be a first step (so the snap maintainers should follow this) the firefox about seems like mostly useful example (141.0 64-Bit, Mozilla Firefox Snap for Ubuntu, canonical-002 - 1.0).
Way out of scope: Something like this might even make sense for traditional package managers (to show if e.g. the program comes from a 3rd party repo or from universe etc). Probably automation would not really work, so one would need to use another program to extract it and mixes it with package management info e.g.
u@linux:~$ versioninfo --verbose /snap/bin/firefox firefox-esr
Name Version Repository Maintainer BuildRevision
firefox 141.0-2 snapcraft.io:latest/stable Mozilla 6565
firefox-esr 128.13.0esr-1~deb12u1 debian.org:bookworm-security debian ef601af63
A desktop feature I would like to have: restrict certain snaps to certain user groups
I sometimes use different local accounts as profiles and to isolate data and usages; so e.g. i do not need my personal data account ever to start any games; and for the gaming-user it is fine to use x11, but not for any other account. Also relevant for other interfaces like desktop-legacy
Side-note: Also disconnecting the x11 interface won’t work on e.g. debian to prevent snaps from accessing x. So separate users help in this case.
So e.g. restricting snap the-powder-toy to the group gaming-user would add restricted,groups=gaming-user to the Notes
Name Version Rev Tracking Publisher Notes
the-powder-toy v99.3.384 54 latest/stable james-carroll* held,restricted,groups=gaming-user
snap run would prevent execution (printing an error) of the-powder-toy for all users without the gaming-user group. A nice-to-have would be -if it is possible- to not provide the executables in the path
After placing a hold on a snap, there should be no notification indicating that the snap will be refreshed once the application is closed until the hold period ends. Since a held snap is not actually refreshed upon closing the application, the notification is misleading and counterintuitive.
This is more a feature quest than a papercut, but it would be helpful if a global snap refresh on the command line would list any snaps that could not be refreshed because they have running processes. Right now this feedback is only provided for a specific snap when running snap refresh <snap name>. Perhaps there is a clear rationale for this behavior, but I always find it confusing to get a message stating All snaps up to date when there are actually snaps that are not up to date.
Actually I think i never saw a notification for held snaps (Kubuntu 24.04 KDE). For some snaps i would like to get a reminder if there is a new version available, even if those are on hold; but to be useful that would also need a list of changes. I use this for snaps which do not communicate with external data/the net. One advantage is stability (bugs as well as GUI) and another is less attack surface - if a maintainer/publisher gets pwned, a single infiltrated revision is enough to expose the (containerized) linux account and connected interfaces to malware. I think there are better solutions for my use case though (e.g. snap refresh --list optionally showing refreshables for held snaps)
add an option or similar to snap refresh --list, so that the version and revisions of the refreshable snaps are shown. Which makes most sense in combination with the second papercut:
add an option or similar to snap refresh --list, so that also held snaps are listed.
My workaround is to have a script iterate through the list of snaps (snap list), parse the channel and grep the info for the installed version and the followed channel from the info (snap info).
I got a single notification after I set a hold on a package. This was within a few hours of the hold being set, so perhaps there was just a delay in processing the hold. I haven’t seen any notifications beyond that first one, so it could have been a fluke.
When doing snap refresh -revision with the revision being available on a different track, the message is misleading (e.g. when following track latest/stable and the revision is available on latest/candidate)
Channel latest/stable for thunderbird is closed; temporarily forwarding to candidate.
So I guess the message actually means ‘Revision 769 for thunderbird is not available on channel latest/stable; it is currently published on channel latest/candidate.’ or
‘Revision 769 for thunderbird was never published on channel latest/stable; temporarily forwarding to candidate.’.
Also the ‘temporarily forwarding’ is a bit cryptic. But it may make sense, depending on how the store is implemented.
If this were to be done right, it’s a bit larger piece of work. Can you open a separate forum topic describing this feature? Or maybe I can split your post into a separate topic.
I see what you mean. We do not have anything like that right now, because the commands you’ve listed operate or track the current state only. In theory this information, and more, should be visible in the output of snap change --last auto-refresh (or --last refresh). Perhaps we need a better way of showing this information and consolidate it under snap refresh command.
