Call for testing: chromium-browser deb to snap transition

This won’t help with root, but you should be able to access files on USB sticks if you connect the removable-media plug:

snap connect chromium:removable-media

What is your theme?

This is being tracked by bug #1847069.

Can you please file a bug for this issue?

beyond the fact that the chromium snap is actually smaller than the deb (and gets never unpacked on disk due to being a squashfs), it should keep only three revisions by default, not sure how you happen to get four (initial install (to be able to go back to a “factory” state), last revision (for automated rollbacks) and currently used revision).

you can turn that down to two (not less because of the transactional auto-rollback that is builtin into snaps) via:

sudo snap set system refresh.retain=2


Do you have any other “tips & tricks” like that, for things that don’t happen automatically? If there are a few, it might even make a good blog post or something.

1 Like

The Ubuntu Software app has also graphical management for the interface connections so you don’t have to resort to teminal/cmdline, here is a screenshot (from


Whenever I’ve used that setting, none of my manual set settings would stick.

One item that has bothered me from time to time, but forget to report is the lack of support for gpg with the Chromium snap. GooPG, extension for Gmail encryption, doesn’t work with this snap.

you should file bugs about these two issues … if you dont tell the developers, they wont know and wont fix it :wink:


The snap is working. Bookmarks are there along with stored username and passwords.

What is NOT working is access to file partitions other than ~HOME, which completely breaks my workflow. Have had to resort to Firefox, which is fine, but I run both routinely.

I have control of my computer and, frankly, resent being “reigned” in. Better is to let me do what I want without restrictions.

Apparently there is a workaround to install the snap with a --classic switch. I have not tried it.


Did anyone get chromedriver working with the chromium snap? The project I’m working on has a test suite built with Robot Framework’s SeleniumLibrary, which worked fine on Ubuntu 19.04, but now it fails on startup with mysterious

WebDriverException: Message: unknown error: Chrome failed to start: exited abnormally
(unknown error: DevToolsActivePort file doesn’t exist)
(The process started from chrome location /snap/chromium/current/command-chromium.wrapper is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

There are a bunch of messages in journalctl about

lapkr. 12 10:36:04 blynas audit[25465]: AVC apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromedriver” name="/proc/25465/mem" pid=25465 comm=“5c95b28f4a1b1d7” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000
lapkr. 12 10:36:04 blynas kernel: audit: type=1400 audit(1573547764.515:133): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromedriver” name="/proc/25465/mem" pid=25465 comm=“5c95b28f4a1b1d7” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000

but I don’t know if that’s the cause of it or not. (Why does chromedriver want to access its own /proc/$pid/mem anyway?)

1 Like

Please note this is not a workaround. The --classic option only allows you to install a snap that is already confined with classic confinement, it does not switch confinement from strict to classic. See for more details.


Is there an easy way to access partitions with snaps?

Well, in that case the --help switch might be identical to the man page. In almost all cases those differ and the separate man page is more comprehensive than the help switch.

This lack of exposure to the GNU userland is the whole reason for my criticism. All those common GNU commands do not work anymore: man, info, whereis, whatis and probably a lot of others.

Every new app that is “snapped” will become a stranger to the underlying GNU-(user)land. That is a conceptual flaw which should be fixed with high priority.

re: man pages from snaps, the snapd team has started to look at how to expose man pages from snaps to the host system. I can’t say when this will be completed, but it is on our radar as an issue we intend to fix in the somewhat near term.

1 Like

The easiest way is probably to setup bind mounts from your other partitions to removable-media directories such as /media or /mnt.


Hi @oSoMoN

This is the current user agent string of the snap:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/78.0.3904.97 Chrome/78.0.3904.97 Safari/537.36

This is the user agent string for the deb package:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/78.0.3904.97 Chrome/78.0.3904.97 Safari/537.36

I can confirm that works if I change snap to Ubuntu in the user agent.

Is it possible to reconsider having a separate browser string for the snap? Given that a website as popular as doesn’t work, it probably won’t be the only one. I’ve had to contact so many websites because they incorrectly blocked Linux and Chromebooks, I’d hate to have to do this again for the snap now.

Moreover, having a distinction between the snap and deb user agent increases the browser fingerprint, making it easier for websites to track us without our permission.

Given that the Chromium snap is strictly confined, chromium is in fact running in Ubuntu as far as Chromium is concerned.

Ubuntu used to include the version number in the UA, but this hasn’t been the case for a while now. I suspect that was removed for similar reasons.


I have set snap set core experimental.refresh-app-awareness=true but I keep losing some data when snap updates.
I usually never restart chromium (30 days uptime on my laptor currently). And here what I think is happening:

  1. snap updates, copies .config/chromium
  2. I keep using old version of snap which is using old .config/chromium
  3. After couple of hours I open some url from another app (executes chromium https://...), running version of chromium crashes (maybe because newly executed chromium points to another .config/chromium).
  4. New version of snap executes, but missing a data from those couple of hours. And I can confirm this data in .config/chromium of old version of snap.

This will probably affect few people but I pretty much immediately discovered that the snapped Chromium could not access files in hidden directories. (I extensively use .local/opt, .local/src, .local/include, etc. – so I guess it was bound to happen sooner than for most people.)

GooPG uses native host messaging, which currently won’t work because of bug #1741074.

1 Like

Chromedriver is working here with the snap. You can have a look at the snap’s own basic tests, which are installed in /snap/chromium/current/tests/, for example the chromium-version test.

The most important bits are:

options.binary_location = "/snap/chromium/current/command-chromium.wrapper"
driver_path = "/snap/bin/chromium.chromedriver"

I haven’t had a chance to test this with more complex setups though. If this doesn’t work for you, please file a bug with details about your setup. Thanks!

This is very unfortunate. It’s 2019 and companies still produce web pages that enable/disable features based on UA sniffing. I’d suggest using an extension (e.g. User-Agent Switcher for Chrome) to work around the problem.

The “snap” token was added to the UA string initially to allow to identify unambiguously a system that knows how to handle snap:// links, to provide accurate installation instructions. This isn’t ideal, but it’s not something we can easily revert either.

Indeed. An extension to override the default UA string sounds like a good mitigation for privacy concerns.

That’s not quite correct. The app is running on whatever the host system is, but it has a very limited view of that system. The fact that the snap was built on Ubuntu is an implementation detail, even more so in the case of chromium which embeds and builds many of its dependencies at build time.