Disabling automatic refresh for snap from store

What about playing around the refresh.timer to give it an unreachable day through setting a cronjob :
0 0 */5 * * /usr/bin/snap set system refresh.timer=$(/bin/date --date "-1 days" +%a | /usr/bin/tr '[:upper:]' '[:lower:]')

or downloading a snap and installing it without the .assert file.

It’s trivial to disable auto-updates on those platforms. Each of them includes a simple “do not automatically apply updates” option. In my mind, that disqualifies every one of them as a valid example.


It’s been almost two years (and ~200 comments) since I originally participated in this discussion. At work, we are once again doing some evaluations of how we package and distribute software for some of our platforms and how we manage some of our systems, and snappy still strikes me as having a lot of great potential for us.

Unfortunately, I see that this is still an unresolved request, and after reading through the comments, it seems pretty clear that a simple method of supporting manual updates (and disabling forced automatic updates) is never going to happen. I could go through and explain our internal processes and some of the contractual and regulatory requirements that require us to certify systems and not make changes to them for set periods of time (and yes, they’re typically greater than 60 days). I could explain the process we go through to secure the systems and mitigate the risks. I could discuss how the various teams managing the platforms need to careful plan and schedule their upgrades and changes on their own timelines, separate from when updates are pushed by developers.

But, it isn’t really going to make a difference, is it?

You want to force a strict update process that matches your idea of how things should be done, and I’m just interested in what seems to be the best available cross-distribution software packaging system. . . and in managing my systems.

The simple fact is that for my use case (and many others), this lack of functionality makes an otherwise really useful piece of software into a simple non-starter. It just can’t meet my requirements. And no, I’m not willing to muck with firewall rules to work around it, and I’m really not going to work around this snappy limitation through additional software like the (proprietary) proxy (I’m not interested in dealing with the additional overhead and complexity there).

From the discussion, it appears that the bar for evidence to justify a straightforward option to disable auto-updates has been raised higher with every request for the feature, and it doesn’t look like it’s ever going to be met. I concur with a few previous suggestions: at this point, after more than two years, the request should probably just be closed as “won’t fix” so people can realize that it’s not going to happen.

I still really like most of the ideas and technology behind snappy, but I can’t compromise on one point: I am the one that know what’s best for my systems. And, as I am the one responsible for them, I will always need the ability to control them, including updates. We’re not willing to risk our systems and our revenue on unexpected or uncontrolled software changes. End of discussion.

It’s interesting that I can’t think of any other single platform anywhere that has taken such an overbearing and high-handed approach to updates. Not one. Perhaps there are good reasons why that is?

Regardless, congratulations on the very cool technology you’ve produced. I just wish it didn’t come with such forced ideology.


I think I just had a realization. Perhaps my frustration is my fault, in that I was trying to look at snappy as a truly universal cross-distribution software packaging system. That seemed like the goal to me.

Now, however, after reading some of the comments on External repositories, I think I see my mistake and misunderstanding. Snappy isn’t the universal cross-distribution software packaging system I was looking for. It’s the cross-distribution end-user-focused software app store I wasn’t looking for.

I’m approaching this from the IT professional and system administration perspective, and trying to solve enterprise system and software distribution/management/update problems. I thought I could make Snappy fit into that, but I now suspect that I was wrong, and that Snappy doesn’t actually care about my problems (at least not if they in any way conflict with the goals of being an end-user focused app store (with an excessively strictly enforced update ideology)). Perhaps I’m not the only one to make this mistake?

I would never put Snappy on any server I’m responsible for because the current design is broken from an enterprise system administration perspective (at least, it is to me). However, from a user desktop or laptop perspective, Snappy’s forced updates are maybe (slightly) less obnoxious.

I still fundamentally disagree with the update stance (see previous comment about not being able to think of any single platform that is so determined to force its views on updates on people), but since it seems intended for a different use-case than mine, I’ll just move along and focus on alternatives that fit professional systems engineers better.


Experienced system administrator here. It’s crucial for me to keep my systems running. I don’t want nor need to auto-update snaps which could potentially introduce critical bugs and require manual interaction to fix them (not always possible without causing downtime).
Please provide a way to (optionally) disable snap updates.


I spoke to one of the Canonical sales rep about this and he told me the suggested approach is to pay for a branded store (currently 15K per year) where you control all the snaps in it and when they get released. This should solve the problem for critical (i.e. commercial) solutions that need to have tight control (when updates get released) over their systems. Am I missing something? or is this discussion more about the principle (FOSS etc)?
I didn’t see mention of this fact in this thread so I’m adding it to make it more visible as it seems to solve the practical problem

my conversation with the canonical sales rep was in a commercial context. I don’t know anything about a branded store for an opensource/community project

I’m a simple user with a couple of Ubuntu installs on personal computers that are only mission-critical to me, so feel free to ignore my comments.

I would very much like the option to stop applications from being upgraded, and while I understand the security concerns, I do not mind them.

With that in mind:

I suggest you make it difficult for the user to opt-out of the auto-update — something like; having the option only available through a root-only config file where the user must white list the apps they want to freeze. Or, a read the terms of service, a la Firefox’s “here be dragons.”

On top of that, The system could pester users with options to opt back into the updates with every new refresh window.

My humble proposal, I believe, gives users choice, and makes use of behavioral nudges to address some of the point expressed by @niemeyer et al.

Thanks for all the effort.

You’re right, a brand store allows for customers to make sure a given combination of snaps are well-tested before releasing them into their private slice of the store. That can technically be used to disable updates, but that’s not its intended purpose. It’s really just that the brand store maintainer has the ability to act as a gatekeeper for what they let into their store. Devices must be specifically configured to communicate with that store, and all the logic is store-side: it would be controlled by the company who owned the store, not the end users of the device. The fact that users can’t control it seems to be the issue here.

ah ok. that makes sense. i figured i was missing something

Thank you for clarifying

I’m trying to design a quick survey to give a perhaps wider perspective on how users, and contributors feel about this feature. My hope is that it will provide some insight to the number of people impacted by this, and some of the issues they’re facing.

Bellow there’s a straw poll with the sorts of questions that I believe could further inform this discussion.


I’d love to get some input.


Edit: typos


Most of you think this is a technical matter. It isn’t.

This is a way for Canonical to

  1. Wrest as much control from us as possible
  2. Create their own app marketplace
  3. Force us to buy, update and maintain according to their schedule, not ours

It’s a business decision.

If it weren’t a business decision, and every sysadmin and power user everywhere would be opposed to it, then what would Canonical do? It would allow us to disable auto-updating, and apologise.

But they’ve stuck to their guns. Why? Because it’s a business decision.

It’s a private company, and doesn’t owe me a thing. But, this is precisely why I left Windows! And this is precisely why every time I upgrade a system, I replace Ubuntu.

I’m using linux because I want complete control. If you take that away from me, I won’t use your product. If you want to be the new Microsoft or Apple, good luck to you (I mean it, no hard feelings), but good bye.


What about only allowing the packagers (rather than the users) to disable automatic updates? Can’t we expect them to behave more “responsibly” than the users with this freedom?

packagers have full power over releases indeed. if you dont want to update your users, just keep your snap in a non-stable channel in the store (you have four by default) … push to stable only if you want to update …

1 Like

Snaps seem to be a great idea and I’ve already seen various improvements in the short time I’ve been using them. I don’t particular notice the speed problems people talk about.

Yet, this issue just seems like one where the business requirements of SNAP’s users don’t match what it is being designed for. It ‘looks’ to me like that snappy design team is viewing the SNAP store like the Google Play Store or something. Primarily something to be used by average users on their home devices (like smart phones). So… why not force them to keep it up to date?

Yet, the SNAP store is being viewed by its user base as a general linux application deployment system. The original post is really a great example of why the auto-update system breaks these use cases. If it’s doing any kind of services/networking, you can’t just have it auto update. Not to mention most organizations have rules and processes in place that they expect the software to be subservient to. Not the other way around. You don’t buy/install software and then rewrite your business processes. You buy/install software that meets your business processes.

I’d really suggest if this hard line is going to stand, just come out and say that the SNAP store is unsuitable for general enterprise use. Developers, such as the OP can then host local SNAP files on an FTP server or something. Their user base can then update it manually to their hearts content. Or maybe you push people on those cases to use private SNAP stores, where those kinds of options can be configured.

Alternatively, I really like one of the suggestions I read where there is a file where you can configure SNAPs which should not be auto-updated. You can even make editing this file require root. You can even mandate it is the exact file name, and not some regex. This would really emphasize that you need to add apps manually and not just * I really like this idea because

  1. It keeps apps up to date by default
  2. It makes non-auto-update apps an exception. For example, in the OPs case, his customers might only want to have his SNAP not auto-update. But other SNAPs which might not cause downtime can auto-update.
  3. The non-auto-update apps are all tracked in one place. This is great from an audit point of view; especially in the enterprise. To put it bluntly, whoever made that change to exempt that SNAP will be responsible if a non-updated app causes problems.

This could also be used in conjunction with a flag on the SNAP itself which indicates if the developer of the SNAP allows the SNAP not to auto-update. Feel free to have whatever process in place to approve that flag. That at least shifts the point of contention to developer-SNAPSTORE. For example, if there was ever a valid use case, the OP (networking products) should definitely get approved for such an flag. I just throw this in as no doubt you want to avoid everyone throwing that flag in there by default. You want to keep such things the exception.


I was frustrated with MS-Windows updating itself, and looking to Linux for some sanity. Looking for an alternative to Notepad++ and found a suggestion to use the packaged version available with Snap. Arrived here after finding to my horror that Linux is starting to suffer the same ‘forced update’ hell that MS-Win is. Or so I thought.

There is a philosophical problem here. The users are of the opinion that “it’s my computer so I’ll decide what runs on it” and the software authors are of the opinion that “it’s my software so I’ll decide how it runs” and these two are in conflict. Ultimately, the user must win, or at least have the option to, even if they are shut out from using the finest software.

There is, of course a tiny glint of a reason why forced updates might be a good idea; bugs in libPNG, the whole Heartbleed issue, in these cases it helps to centrally shut down the vulnerable software before the scammers all have our credit card numbers; but the software companies are in my opinion hiding behind this ‘security shield’ and using it to push unwanted ‘enhancements’ on to users, as well as taking away useful features.

I have many examples of software that I’ve used which has one day become unavailable, either because it was written to time out, or because “the free version is now deprecated” and I am now adamant that the only safe software is software you can compile yourself, because if there is a time bomb in there, you can find it and remove it. Even paid software is unacceptable—I paid for MS-Win10 after all—because the authors (owners of the software) still have control.

Apparently Snap allows you to roll back to a previous version if you’re not happy, but since snap itself can be updated, this ability could be withdrawn—do you see the problem now? It’s all about control, and whose computer it is.

The obvious retort to my whine is “if you don’t like it, don’t use it” and of course this is exactly what will happen. I will find a Linux that doesn’t use Snap, and I will learn to live without Notepad++. It’s worth it, because it’s MY computer.

sudo systemctl stop snapd.socket
sudo systemctl disable snapd.socket

This has disabled command line snap install & refresh so may work at the schedule level (tried on OpenSuSE Leap 15.1). I have captured the snap list in a file and will be comparing over the next few weeks to see if there are later revisions available and the revision status on my pc.

Obviously one must restart these to re-commence their functionality. I run a once annual update to the distro and if I were to allow snap auto-updating and one of my users was able to use a function from a later revision package on one computer but then sat at another and could not costs me support money. It’s that black and white.

1 Like

This issue sounds like a bug, could you please either start a new topic or file a bug on bugs.launchpad.net/snapd about this so we can take a look at that?

My Bad !!! need second morning coffee!!!

This is the actual report:

snap install blender --revision=34


error: cannot install “blender”: Access by specifying a revision is not allowed for this Snap.

It looked like the maintainer of the blender snap is working on making the 2.81 and 2.82 versions of Blender available via tracks. This will mitigate the automatic update system you’re unhappy with. You’d be able to sit on the track required which contains 2.81 and stay there.

1 Like

As you can see I have only recently joined the discussion. I read all the posts. As an experienced systems administrator I Identified there were certain features that users without system admin exposure thought should be there but some may not have known the exact terminology required to articulate.

In short, it seems to me if auto-updating can be blocked/enabled at will and this easy to use ‘tracks’ system where by selective revisioning can be employed either for a home user machine, or across a pool of machines using a standard build (soe) this would summarily describe the management requirements of both home users and system administrators - and whilst there may be a little more invited to add to that description then SNAP certainly sounds like an evolved “repository” ecosystem highly worthy of application on many distros.

On a personal note I find SNAP satisfactory to my requirements because the audio/video multimedia apps are literally bleeding edge releases containing the h264/mp4 codecs that I would otherwise have to mix and match from the packman repository - which on an OpenSuSE Leap box can lead to all kinds of update source confusion down the track because of the arbitrary nature of it’s repository priority numbering.

So ‘hats off’ to SNAP as a solution.