Snap refresh fails due to filesystem snapshots

Due to my filesystem layout, I’m unable to update snap apps.

I use BTRFS with the following subvolume hierarchy (the snapshots are read-only):
–root
|–home
||–<user_dir>
||–weekly_snapshot_of_<user_dir>
||–monthly_snapshot_of_<user_dir>

Attempting to update snaps with the refresh command always fails since write access to snap directories within the snapshots is not permitted.

Is there a way to update a snap by either:
a) explicitly specifying the sole user snap directory to be refreshed?
b) setting a list of locations to be ignored?

Or perhaps I should report a bug somewhere?

CC @chipaca

I think this falls on my plate soon but I need to look at many other factors first.

Any workarounds I can employ in the meantime? I’d like to keep using an up-to-date browser.

You could snap remove and then snap install? :stuck_out_tongue: You would lose all the data for that browser each time you do so, however (I think)

I’m not keen on setting-up all my browser settings and extensions each time so I’ll make a copy of the browser profile before re-installation.

Let’s see if restoring the old profile prior to first running the newly-installed snap will ensure the old settings are retained.

For reference sake, it’s worth mentioning that copying profile data restores settings. But, of course, this doesn’t address the problem.

I was forced to remove all snapshots in order to refresh the snap app since the refresh process is unable to distinguish between user home directory and a Btrfs snapshot of the same directory that exists at the same hierarchical level. Without removing snapshots, the refresh process fails every time.

Removing snapshots is neither practical nor desirable so until this problem is addressed, keeping a snap updated is impossible.