Lost config/state access after chromium snap is refreshed

I have [previously reported that snap refresh affects Chromium quite badly as a running instance loses all read/write access to it’s .config directory and thus would be unable to update or load any state (history, password, etc).

I had moved back to the distro’s debian package, but since this is no longer an option on newer Ubuntu releases I went back to using the snap chromium. Unfortunately the bug is still there, thus I decided to open a specific topic to talk about this.

What is particularly annoying is that there is no way to tell that chromium snap was updated and that from there on state will no longer be saved. The issue sits silent until the the browser is closed and open again. I consider this a very serious problem and affects users in various ways:

  1. Passwords: the option to save password is there and when used it seems to work because Chromium doesn’t explicitly say that is was actually unable to do so; at the same time chromium is unable to access the password config file and will no longer provide autocomplete; the saved password list is empty. This is usually the way I can tell that a possible snap refresh occurred.
  2. Tabs, history: opened/closed/changed tabs after the snap refresh won’t show up when chromium is restarted; all history after the snap refresh is lost.
  3. Notification: chromium does not seem to have ways to notify users that it has lost read&write capabilities to its own configuration files - in fact I am amazed that it can continue running with so few signs that something has gone terribly wrong.
  4. Refresh: snap refreshes chromium and updates its apparmor profiles even when an instance is running, thus removing read&write capabilities from the running instance to its configuration files.

I would appreciate any pointers on how to solve or workaround this - besides playing around with the apparmor profiles - and would like to know if there are any plans to fix such problems.

Best regards

1 Like

FWIW I don’t think it’s precisely true that chromium loses access and can’t write its config. Rather, I believe what happens is that a copy of the per-snap-version data is made while chromium is still running, so the running browser writes to ~/snap/chromium/<oldver> and after a restart, chromium is reading from ~/snap/chromium/<newver> which is a premature copy.

So you should be able to work around the dataloss by, after stopping chromium, removing ~/snap/chromium/<newver> yourself and copying ~/snap/chromium/{<oldver>,<newver>}.

I also filed https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1852809 about this issue.

This is unfortunate indeed. It doesn’t affect only chromium but potentially all snaps, although it’s probably more visible and annoying on chromium.
This is being addressed in snapd with [WIP] Refresh App Awareness. Until this is on by default, I suggest enabling the experimental feature. I’ve had this on for a few months and it works well:

snap set core experimental.refresh-app-awareness=true