Library missing after restarting machine; Flatpak looped directory missing

[rdrms]

I have a music directory that is not in ~/Music, but rather \~/Storage/Music, which is another drive (\~/Storage/) mounted in the home directory.

I had the issue of Lollypop always saying "Scan disabled - missing collection" after ever reboot (and perhaps every relaunch of the application) of the system. I used Flatseal (great app for flatpak permissions) to allow it access to the home (~) directory, which solved the issue. You could also do the same with the command line with flatpak override.

Just wondering if maybe that could be added to the README for instance, just in case others run into the same issue maybe they will find this post. I know there is already a mention of allowing access to the host's full filesystem but perhaps this would be helpful. Thanks for packaging this excellent program, thank you!

[Eonfge]

Mmh. Sounds more like you have an issue with mounting disks. I also have my music collection on a different partition but I don't have the issue you describe.

How and when do you mount the music partition? Could you share your /etc/fstab?

[rdrms]

I forgot some details that might be pertinent. I'm running Fedora Silverblue, if you're not familiar the main filesystem is read only, while the read/write portions are mostly contained in /var, including the home directory which is /var/home

My fstab looks like this:

UUID=<uuid#1> /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=<uuid#2> /boot                   ext4    defaults        1 2
UUID=<uuid#3>         /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=<uuid#1> /home                   btrfs   subvol=home,compress=zstd:1 0 0
UUID=<uuid#1> /var                    btrfs   subvol=var,compress=zstd:1 0 0
UUID=<uuid#4> /var/home/rdr/Steam   btrfs   defaults 0  0
UUID=<uuid#5> /var/home/rdr/Storage btrfs  defaults 0   0

As far as I know, this is the correct way to mount volumes on Fedora Silverblue (with the /var/home path instead of /home). I might be wrong. I just did a relaunch and then a reboot, and no more problems with "Scan disabled" anymore with the permissions tweak.

[Eonfge]

Ow, I love Fedora Silverblue. It's the future of Linux and you can see the first production systems like Steam OS adopt a similar methodology.

This sounds like something that Upstream should perhaps look at. See; when you add the music folder to your Lollypop config, the Flatpak file-manager creates a symlink in the /run/ directory. This way, the application can access all the files you just gave access though, but it can only access those files through the symlink.

Have you looked at the Flatpak project itself? https://github.com/flatpak/flatpak/issues

Perhaps you found a Flatpak bug because from my point of view, everything should have worked.

[Eonfge]

I stumbled on this myself now. Only happened to me once now, so it might be unrelated, but I'll keep this issue open for further analysis.

[Eonfge]

I'm trying to pin point the issue; See if it's Flatpak or Lollypop related... Can you try something?

When you add your music library, it should sylink to a folder like this; /run/user/1000/doc/57297c26/Music/

the 1000 is your user-id, 57297c26 is random, and then it should contain the folder with your music. I want to ask you to write down the number path and see if it changes after a restart. That would indicate an issue with Flatpak itself. Please tell me if this gives you anything, wile I try to do the same.

[rdrms]

Unfortunately I can't quite locate the correct folder, as I have a bunch of Flatpak applications which have littered the /run/user/1000/doc/ folder with 205 folders, variously containing nothing, or maybe an image I uploaded with a browser, or a movie file I watched in mpv, or a bunch with a single mp3 in them...

I did try resetting the permissions to remove the ability of Lollypop to see all of /home/my-user/, and it seems to work fine upon application restart after initial setup. I'll update Silverblue and restart the computer and see if the issue persists upon reboot.

So, application restart was fine, but upon reboot it throws this error:

I found two folders with the identifier 170a027f, one in /doc/ which is empty, and another which is in /doc//by-app/org.gnome.Lollypop/, also empty. I hope this helps a little bit I just had a lot of trouble finding which folder i'm supposed to be looking at.

[Eonfge]

Unfortunately I can't quite locate the correct folder, as I have a bunch of Flatpak applications which have littered the /run/user/1000/doc/ folder with 205 folders, variously containing nothing, or maybe an image I uploaded with a browser, or a movie file I watched in mpv, or a bunch with a single mp3 in them...

I did it by searching for song-i-like.flac

And yeah, this does seem to be a Flatpak specific issue. Let's see if I get it as well.

[Eonfge]

Have you recently had this problem? I have not seen it since the last time I talked commented

[rdrms]

I kind of gave up trying to make it work the normal way and just granted permission for Lollypop to see the home directory again. I can try resetting the permission and doing the library again, then restarting. I think it may end up like

^ from an above comment

[Eonfge]

Changing the permissions now, will cause that error to occur again. That's working as designed... although the documentation is quite unclear about it.

For the record, I have not granted any additional permissions and I haven't had it happen again. If you keep your permissions as-is, and nothing changes, then that's a win in my book.

[rdrms]

Ok I’ll try it again and edit the comment with the outcome.

Edit: Still happens after resetting permissions, closing lollypop, and restarting the machine. Might be a flatpak issue like you said, here's the error message, it also says "scan disabled, missing collection"

[Eonfge]

When you change the mount options, even if the folder itself stays the same, it decouples the symlink. Thus, this was expected.

I will keep an eye out in case it happens again, especially since I also had it once.

[rdrms]

So I reset the library, closed the application. Reset all permissions to standard ones (only difference was full access to /home/me), opened it, added the library folder. Let it finish indexing, closed application and then restarted the computer. Opening it again led to the error. Hope this is more clear.

[Eonfge]

So I reset the library, closed the application. Reset all permissions to standard ones (only difference was full access to /home/me), opened it, added the library folder. Let it finish indexing, closed application and then restarted the computer. Opening it again led to the error. Hope this is more clear.

Mmh. @bellegarde-c Could there be something wrong with storing the file-paths if loading from /run/user/1000/doc/XXXXXX ?

[bellegarde-c]

I cannot confirm the issue.

music-uris=['file:///var/home/gnumdk/Musique/Collection', 'file:///run/user/1000/doc/22027277/Sex%20is%20Muss']

I guess the issue is related to KDE xdg-portal not mounting directory on next run.

[rdrms]

I guess the issue is related to KDE xdg-portal not mounting directory on next run.

It was also an issue on Silverblue running GNOME, see the screenshot from Aug 23.

[bellegarde-c]

I use Silverblue and does not happen here :(

[bellegarde-c]

$ flatpak run --command=sh --devel org.gnome.Lollypop

So the portal automount the folder here...

[Eonfge]

I've had it twice more. This weekend, when I was not in the mood for debugging, and just now. When I go into the flatpak container I get this;

[kevin@kevin-fedora-desktop /run/user/1000/doc]$ printenv
SHELL=/bin/sh
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1986,unix/unix:/tmp/.ICE-unix/1986
__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS=/etc/egl/egl_external_platform.d:/usr/lib/x86_64-linux-gnu/GL/egl/egl_external_platform.d:/usr/share/egl/egl_external_platform.d
COLORTERM=truecolor
XDG_CONFIG_DIRS=/app/etc/xdg:/etc/xdg
HISTCONTROL=ignoredups
XDG_MENU_PREFIX=gnome-
HOSTNAME=kevin-fedora-desktop
HISTSIZE=1000
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
XDG_DATA_HOME=/home/kevin/.var/app/org.gnome.Lollypop/data
XDG_CONFIG_HOME=/home/kevin/.var/app/org.gnome.Lollypop/config
XMODIFIERS=@im=ibus
DESKTOP_SESSION=gnome
LC_MONETARY=nl_NL.UTF-8
FLATPAK_ID=org.gnome.Lollypop
EDITOR=/usr/bin/nano
PWD=/run/user/1000/doc
ALSA_CONFIG_PATH=/usr/share/alsa/alsa-flatpak.conf
XDG_SESSION_DESKTOP=gnome
LOGNAME=kevin
XDG_SESSION_TYPE=wayland
SYSTEMD_EXEC_PID=2040
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.VCPHV1
SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0
container=flatpak
GDM_LANG=en_GB.UTF-8
GI_TYPELIB_PATH=/app/lib/girepository-1.0
MANGOHUD=1
HOME=/home/kevin
USERNAME=kevin
LC_PAPER=nl_NL.UTF-8
LANG=en_GB.UTF-8
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;37;41:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.m4a=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.oga=01;36:*.opus=01;36:*.spx=01;36:*.xspf=01;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:
XDG_CURRENT_DESKTOP=GNOME
VTE_VERSION=7000
WAYLAND_DISPLAY=wayland-0
AT_SPI_BUS_ADDRESS=unix:path=/run/flatpak/at-spi-bus
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/4d4deeda_777d_4cf3_a7fe_afa8e826bef0
PULSE_CLIENTCONFIG=/run/flatpak/pulse/config
STEAM_FRAME_FORCE_CLOSE=1
XDG_CACHE_HOME=/home/kevin/.var/app/org.gnome.Lollypop/cache
GNOME_SETUP_DISPLAY=:1
XDG_SESSION_CLASS=user
TERM=xterm-256color
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=kevin
GNOME_TERMINAL_SERVICE=:1.171
SHLVL=2
FLATPAK_SANDBOX_DIR=/home/kevin/.var/app/org.gnome.Lollypop/sandbox
QT_IM_MODULE=ibus
LC_MEASUREMENT=nl_NL.UTF-8
XDG_STATE_HOME=/home/kevin/.var/app/org.gnome.Lollypop/.local/state
LD_LIBRARY_PATH=
XDG_RUNTIME_DIR=/run/user/1000
PS1=[\[\]\[\033[38;5;4m\]\u\[\]\[\033[38;5;15m\]@\[\]\[\033[38;5;4m\]\h\[\]\[\033[38;5;15m\] \[\]\[\033[38;5;2m\]\w\[\]\[\033[38;5;15m\]]\$ \[\]
DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ 
LC_TIME=nl_NL.UTF-8
GST_PLUGIN_SYSTEM_PATH=/app/lib/gstreamer-1.0:/usr/lib/extensions/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
XDG_DATA_DIRS=/app/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share
PATH=/app/bin:/usr/bin
GDMSESSION=gnome
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/flatpak/bus
ALSA_CONFIG_DIR=/usr/share/alsa
MAIL=/var/spool/mail/kevin
PULSE_SERVER=unix:/run/flatpak/pulse/native
LC_NUMERIC=nl_NL.UTF-8
OLDPWD=/home/kevin
_=/usr/bin/printenv

[kevin@kevin-fedora-desktop /run/user/1000/doc]$ ls /run/user/1000/doc/16767d4/
Music

@bellegarde-c Could it be that the mounting goes well, but that Lollypop forgets the directory? Right now, the runtime still has access to the music Lollypop can't find it any more. As it stands, it seems that Flatpak does everything right, but for some reason Lollypop can't remember the directory from last time.

[Eonfge]

I'm not sure what changed, but I now have this continuously. @bellegarde-c Are you any closer to a solution?

---

For the time being, I'll be switching to the dnf version of Fedora Linux

[bellegarde-c]

@Eonfge Does not happen here on PMOS and Silverblue but music-uris is set.

[gnumdk@arch ~]$ grep music .var/app/org.gnome.Lollypop/config/glib-2.0/settings/keyfile 
music-uris=['file:///var/home/gnumdk/Musique/Collection']

Looking at the code, this can only happen if:

• music-uris is empty
• GLib.UserDirectory.DIRECTORY_MUSIC (XDG_MUSIC_DIR) is broken

[bellegarde-c]

Hello @Eonfge

Give it a look again, works on Droidian/pmos/Silverblue here.

●[~] cat .var/app/org.gnome.Lollypop.Devel/config/glib-2.0/settings/keyfile 
[org/gnome/Lollypop]
notification-flag=2
window-maximized=false
window-size=[1272, 923]
window-position=[35, 32]
music-uris=['file:///run/user/3121/doc/6fff80a0/Afrique']
volume-rate=1.0

This is how Lollypop store music path (music-uris). Can you check what value is put here on first run and if something changed when it fails ?