Setting $HOME in snap to user home seems to cause all empty user dirs to become broken symlinks

snapd
1

I was trying to push an update for my snap seafile-gui today, and in some preliminary testing, it seems that when testing it so far on a ubuntu machine, all empty user dirs (such as ~/Downloads) are broken and turned into symlinks of themselves. This doesn’t seem to effect ones that have any contents, though.

It looks like some other users have also recently reported this happening to them: https://askubuntu.com/questions/1482903/home-directories-turned-into-symbolic-links-without-telling-me-the-reason

And in my testing, both the snap that they identified as the issue (Okular snap) seems to have the env var for $HOME set to $SNAP_REAL_HOME presumably to fix the app not starting in the right directory. I also used this for my seafile app so it defaults to creating the library in your home directory.

This is just some quick observations though, I might be wrong. It was previously fine with the last revision of core22, built a few months ago, and now after I updated it (by just changing the version of seafile built from git) with no other changes it does break the links. I am guessing it’s some sort of permissions issue on initialization when the home is set to that.

Feel free to look at the github for it and tell me if I’m doing something wrong.

Thank you :slight_smile:

1 Like
2

Here’s a github issue on the topic, which appears to be moribund: https://github.com/ubuntu/gnome-sdk/issues/188

1 Like
3

There is now a fix for this issue and it has been merged.

https://github.com/snapcore/snapcraft-desktop-integration/pull/25

3 Likes
4

Yay, that’s great! Kudos to Sergio! This is a silly question, but would it now be in the version used to build, or would that take a little while?

5

Sorry I have no idea about that.

1 Like
6

Guess I’ll have to do some testing.

7

If you switch gnome-42-2204 content snap to candidate channel the fix is there already.

https://github.com/ubuntu/gnome-sdk/issues/188#issuecomment-2022758747

8

Sorry this isn’t really a solution for Okular.

Okular is after all a KDE program and obviously it doesn’t use gnome extensions.

So the fix must be applied to the kf5 snap extension. That’s what Okular is connected to on my install.

There is a Launchpad bug for Okular, and there is one in the KDE bugtracker.

https://bugs.kde.org/show_bug.cgi?id=482500

Not much happening in both of those. I think we should turn the attention of our great KDE snapcrafters on this issue.

@scarlettmoore could you please look into it. Maybe the fix that was used in Gnome extension can be applied to KDE extension.

2 Likes
9

Sorry I missed this. Looking into it.

10

I have just pushed fix for KDE https://github.com/canonical/snapcraft/pull/4698/commits/221e23cc28896b1098ed4a0c646f00b4b61464f0

1 Like
11

Thank you! You are a true hero.

I just must ask, seeing as the change is for KDE Neon extension for Qt6 / KF6, will the Okular snap switch to that version of KF content snap, and will the Qt5 / KF5 version become obsolete.

12

Nevermind I just so your answer in the KDE bugtracker.

The file actually resides in desktop/common which will be picked up by both the qt5 and qt6 varient.

13

Please test okular in the --candidate channel. thanks

1 Like
14

The candidate channel resolves the bug.

The problem wasn’t to severe, because it only damaged empty directories. If there was even a single file in the directory it remained untouched.

I had two user-dirs, which I don’t use Templates and Publicshare. Theye were damaged by previous version of Okular snap, so to test the new one, I recreated those two directories.

I refreshed Okular to the candidate channel. Then I started it and checked that those two directories are fine. I also looked at the user-dirs.dirs config file and it is all good.

1 Like