Updates delete user/application data

Applications lose user/application data after they are updated - it behaves like a new installation.

Encountered with Chromium, Intellij Idea, Remmina, maybe more.

Chromium loses all user settings, I have to log into it again to have my bookmarks, history etc.
Remmina - the beginning dialogues show up again, all saved RDP connections lost and I have to set it all up again.
Idea - no info about recently open projects, JetBrains account, installed plugins and all other user settings etc.

I don’t know if this is a bug in snap as a whole or only in those apps, but it would be weird if all those apps had the same bug.

Is there perhaps a better place to report this?

This is very weird since it doesnt happen to the rest of us :slight_smile:

normally all user data is copied forward in ~/snap/<snapname>/<snapversion>/ during a snap update.

whats the full output of snap version, do you have any unusual home directory setup ?

this will happen if the user’s home is not accessible at the time of the refresh.

This is documented as not supported in the Limitations in snapd topic, precisely because of this behaviour.

Edit to add: in particular, it’s highly unlikely the data has been deleted, but it’s probably inaccessible to the current revision of the application. As a workaround, with the user’s home accessible, try snap revert chromium, followed by a snap refresh chromium. This will only work if the revision of the application that has the data is still installed (see snap list --all chromium for example, as well as du -sh ~/snap/chromium/[0-9]*)

Unusual home dir setup - I encrypted my home dir using this guide - http://tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html - since new versions of ubuntu-based distros do not offer encryption during installation. The folder is decrypted on login.

snap version

snap    2.42.5
snapd   2.42.5
series  16
neon    18.04
kernel  5.0.0-37-generic

Operating System: KDE neon 5.17 User Edition KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.2 Kernel Version: 5.0.0-37-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 15,2 GiB

yep, that’s not supported

Today after update, mattermost-desktop lost data, so I tried your commands, but encountered error on snap refresh.

First I checked if the previous version, with the data is still there and it seems to be ok:

$ snap list --all mattermost-desktop        
Name                Version  Rev  Tracking  Publisher     Notes
mattermost-desktop  4.3.1    156  stable    snapcrafters  disabled
mattermost-desktop  4.3.2    159  stable    snapcrafters  -

Then did $ snap revert mattermost-desktop which worked fine.

The refresh on the other hand:

$ snap refresh mattermost-desktop 
error: cannot perform the following tasks:
- Copy snap "mattermost-desktop" data (cannot copy "/home/karbo/snap/mattermost-desktop/156" to "/home/karbo/snap/mattermost-desktop/159": 
failed to copy all: "'/home/karbo/snap/mattermost-desktop/156' -> '/home/karbo/snap/mattermost-desktop/159'\ncp: 
cannot create directory '/home/karbo/snap/mattermost-desktop/159/.config': 
Required key not available\ncp: cannot create directory '/home/karbo/snap/mattermost-desktop/159/.local': 
Required key not available\n'/home/karbo/snap/mattermost-desktop/156/.themes' -> '/home/karbo/snap/mattermost-desktop/159/.themes'\ncp: 
cannot create symbolic link '/home/karbo/snap/mattermost-desktop/159/.themes': 
Required key not available\n'/home/karbo/snap/mattermost-desktop/156/.last_revision' -> '/home/karbo/snap/mattermost-desktop/159/.last_revision'\ncp: 
cannot open '/home/karbo/snap/mattermost-desktop/156/.last_revision' for reading: 
Required key not available\ncp: cannot create directory '/home/karbo/snap/mattermost-desktop/159/.pki': Required key not available" (1))

Any ideas?

Also shouldn’t home folder encryption be supported?

I use my linux for work and my company requires us to have the home folder encrypted for security reasons. I imagine many other companies do too, it’s a pretty reasonable requirement.

And with snap becoming very integrated into ubuntu, where the software centre often installs snaps instead of normal packages, it should be working properly.

There should at least be a good workaround.

I’m not sure why you went with that fscrypt thing instead of using full-disk encryption as supported by the distribution, but that was your choice I’m afraid.

Dualbooting with windows. That is why. Pretty common usecase.

that doesn’t follow. You can use full-disk encryption while dual-booting windows. It’s call full-disk, but it’s really full-partition…

Everytime I install Ubuntu it only gives me the option to encrypt disk if I erase Windows. If I choose to install alongside other OSes then it won’t let me use FDE. This is what drove me to fscrypt to begin with.

My workaround is to manually rsync each of these ~/snap/[app]/[version]/ dirs to the new version’s dir.