XDG_DATA_DIRS has a root path /root by default

Affects Rocky Linux 9.8.

XDG_DATA_DIRS has an issue where /root/.local/share/flatpak/exports/share is in the path when using the Gnome desktop. This is impacting software including Evolution.
This does not happen when using ssh to the system. I have checked /etc/profile.d/* and do not see that this happening from there. There is a flatpak.sh but in testing via removal, I do not see a change indicating it is coming from that script.

The extraneous path is “/root/.local/share/flatpak/exports/share”

This issue is happening in a clean install of Rocky Linux 9.8
This issue is not happening in a clean install using RHEL 9.8.

Example from a terminal in Gnome with the bad path:

[admin@localhost ~]$ env | grep XDG
XDG_MENU_PREFIX=gnome-
XDG_SESSION_DESKTOP=gnome
XDG_SESSION_TYPE=wayland
XDG_CURRENT_SESSION=GNOME
XDG_SESSION_CLASS=user
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/admin/.local/share/flatpak/exports/share:/root/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
[admin@localhost ~]$ 

Example from a ssh session:

[admin@localhost ~]$ env | grep XDG
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/admin/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
[admin@localhost ~]$

Verified in a clean installation of 9.8.

A workaround is to launch evolution from an environment where the root entry has been removed.

For example, from a gnome-terminal window launched inside your user desktop session…

$ XDG_DATA_DIRS=$(echo $XDG_DATA_DIRS | tr ':' '\n' | grep -Ev root | tr '\n' ':' | sed 's/:$//g'
$ export XDG_DATA_DIR
$ evolution

Once we verify if this is reproducible in an upstream installation or not we can decide where it needs to be fixed.

Thanks for the report.

Alternatively, remove flatpak, and the problem goes away and Evolution launches fine.

Something with flatpak is messing up the XDG_DATA_DIRS variable.

Incidently, on RHEL9 flatpak package is 1.12.9-4.el9_8.1, on Rocky it still shows the 9.6 one.

One more thing, whilst it doesn’t appear in the XDG_DATA_DIRS when connecting over SSH, it does still appear if you login on a console, eg: CTRL-ALT-F3. So it’s not just related to the graphical environment, but standard tty console as well.

This is confirmed to be a problem in Rocky Linux 9.8 that is not present upstream.

How is it possible that a package in Rocky 9.8 is different to a package in RHEL 9.8? Is this the only package that’s different, or are there more?

The Rocky project rebuilds sources from upstream in a our own build system. It is always possible for builds to be different though we make every effort to ensure that doesn’t happen. It appears this may be a case where a difference slipped through unnoticed.

I understand that, and the build is huge, but wouldn’t there be a log file at the end saying some packages are out-of-sync? Anyway, good news this has been spotted. It still doesn’t fully explain the original issue, even if the flatpak package was the old one, why did it try to use ‘/root’?

I guess that this issues is also related to

Dconf settings on Rocky 9.8

where gdm does not read the local configuration files.

journalctl -b|grep gdm shows a lot of entries like

gsettings[2343]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gnome-session-b[2342]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gnome-shell[2368]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
at-spi-bus-laun[2471]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-sharing[2558]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-sound[2579]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-housekeepin[2582]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-smartcard[2570]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-usb-protect[2562]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-color[2566]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-a11y-settin[2580]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-keyboard[2567]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-wacom[2571]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-power[2583]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-datetime[2576]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-media-keys[2577]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gjs[2765]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:
gsd-xsettings[2581]: Unable to open /root/.local/share/flatpak/exports/share/dconf/profile/gdm:

Adaptation in /etc/profile.d/flatpak.sh does not really help here.

Whan I check in DNF, I see
flatpak.x86_64 1.12.9-4.el9_8.1
so is that the updated package?

Ticket @ https://bugs.rockylinux.org/view.php?id=12904

I have confirmed the update to systemd described here…

Resolves this issue.

I have confirmed the problem on multiple systems.

Alma Linux works fine.

Downgrading to previous flatpak-1.12.9-4.el9_6.x86_64 does not fix the problem.

If I take a working recently patched 9.7 system and only upgrade
systemd from 252-55.el9_7.9.rocky.0.1 to 252-67.el9.rocky.0.1
the problem appears.

It appears to be a problem with the systemd packages.

If I take a fully patched 9.8 broken system and replace the systemd 252-67.el9.rocky.0.1
packages with the systemd 252-67.el9_8.2.alma.1 from Alma linux the problem goes away.

After the systemd update, if you log out or restart your computer the problem disappears:

XDG_DATA_DIRS=/home/ian/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share

no root path now. So the Rocky systemd packages seem to be fine. If you didn’t log out or reboot the chances are the path didn’t update.