In the thunderbird snap, on the first run, if there is an existing ~/.thunderbird profile folder, then the thunderbird snap first run script will try to copy this to $SNAP_USER_COMMON/.thunderbird. If the user’s profile directory is too large to copy, then we run into a problem and it’s not copied and then the first time they launch the snap, it looks like they need to start from scratch. (For complete details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1907184).
This issue would be solved if we could somehow continue to use the existing ~/.thunderbird profile directory with a layout to bind mount it or symlink to it but I believe this snap user data is readonly, and we would need to be able to rewrite to it.
Are there any options for changing the permissions of the user data of this particular snap?
2 Likes
Thunderbird will be making use of a personal-files interface plug; which grants it access to the non-snap files. This interface (subject to review) can be made write rather than read, and then Thunderbird could avoid copying files at all.
Effectively, you’d be able to create a similar experience to the Flatpak. There’s no bind mounts involved, but the result appears the same - this does mean the code may need updating to be able to use the original profile, such as then symlinking from the snap directory to the original.
The reason this isn’t preferred is because it breaks the ability for the user to rely on snap revert, since the profile won’t be versioned with the revision, you can’t guarantee a profile will revert gracefully.
The other reason it’s not preferred is that profile can then interfere with other packages e.g via apt. Not a problem for Ubuntu 24.04, but older bases and other distributions would experience this.
Still, if there’s an apetite for it, it CAN be done.
Thanks so much for the prompt reply!
Sure we could add the personal-files interface plug and do as you suggest (even if it’s not preferred) but the tradeoffs you mention (unversioned profile + possible interferance) are unfortunate.
Would bind mounting not solve both of these cases? With a bind mount, the profile would exist in the location that snap expects and it could be versioned with the revision. And if another package type modified the ~/.thunderbird dir, then that change would be reflected in the bind mount within the snap.
1 Like
Functionally I think the bind mount sounds comparable to the symlink in every practical perspective here. Flatpak uses it because they extensively make use of bind mounts to rewrite $HOME anyway - so it fits in with their existing patterns, whereas Snap makes use of AppArmor to block it off without rewriting $HOME at all, similarly so even for /etc.
I’d expect then that the Flatpak doesn’t handle graceful rollbacks either, although I could easily be wrong.
I also don’t think this is the end of the world, as I look at the Firefox snap for example, it actually stores its content in the unversioned folder, so that can’t do graceful rollbacks either.
These sounds like negatives, but to shift perspective, all this means functionally is you’re in the exact same situation as the Apt package always has been, the Snap isn’t doing anything unique (apart from having to symlink it to begin with).
I would actually like bind mounts in $HOME for other reasons though, sometimes with hardcoded paths it’s easier to just cheat than to patch the source. personal-files always requires review whereas a bind mount could be useful for situations where the original folder contents isn’t needed but the path itself is.
These sounds like negatives, but to shift perspective, all this means functionally is you’re in the exact same situation as the Apt package always has been
Yes I suppose you’re right.
Alright I’ll give the personal-files method a try and then submit the change for review 
2 Likes
Whatever solution is picked, there is no difference between Firefox and Thunderbird that would justify them to be different, correct?
Easiest is to copy Firefox’, which namely checks disk space and only proceeds with the copy if enough is available, else tell the user to figure it out.
If no one says anything against it I will do it.
Oh wait that’s actually the problem Heather is reporting. So we want to change both Firefox and Thunderbird, correct?
