If I attempt a “flatpak update” now all I get back is this
Note that the directory
‘/root/.local/share/flatpak/exports/share’
is not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.
Has something changed with flatpaks recently? I swear I didn’t change a single bit, this just appeared on its own. What am I supposed to do? Thanks.
So, on my system /root/.local/share/flatpak/exports/share is defined in the environment variable. I’m assuming that’s not the case for you? If so, you might need to define the variable in /root/.bashrc (you’ll probably have to create the file).
However… if you are installing Flatpaks as root then now might also be a good time to change that habit and just install Flatpaks as a normal user.
I am not sure if this is regression. Part of the problem might be that flathub is added as a system remote (flatpak --system) (at least it used to be). I have moved flathub to be a user remote (flatpak --user):
$ flatpak remotes
Name Options
flathub user
XDG_DATA_DIRS is set in /etc/profile.d/flatpak.sh. If you run sudo flatpak update do you still see the message?
Anyways, you can move flathub to be an user remote and reinstall your flatpaks as user, the problem should go away.
You can switch to the root user with su (you’ll be prompted for the root password). After that you can run echo $XDG_DATA_DIRS and type exit to switch back to your normal user.
I double-checked this. On Tumbleweek, flatpak is installed by default and flathub is set a up as the only remote. It’s indeed a system remote, so any flatpaks you install via the software center are installed system-wide.
After adding flathub as a user remote (flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo) GNOME Software gives me the option to install individual flatpaks for either the system or user.
Seeing this thread, I had a related question, cause suddenly I discovered that my user available disk space was shrinking and I found out it was caused by Flatpak applications that were being installed under my user partition instead system wide, like any other.
I asked about it to Flatpak developers and they talked me about what you are talking here, “system remote” and “user remote” as you can read here
I’m at a point where, as a simple user who understands that applications should all be installed in the same way (and under the same folders, for compatibility between Linux distributions) I don’t know if the problem of Flatpak applications being installed in my user folder instead of in the system partition is a problem I should raise with the openSUSE developers or the Plasma Discover developers, but I raise the question here because it’s related.
This is not a bug. If you are installing flatpaks as a user installation --user then they are going to be installed into that users $HOME/.var/app IIRC. This is normal, and expected behavior.
System-wide installed flatpaks will end up in /var/app I believe, and are available to all users of a system.
It’s odd that on your system the $XDG_DATA_DIRS variable points to the home directory for the user kp rather than root’s home directory. Maybe someone else who installs flatpaks system-wide can confirm if that’s indeed the issue?
I’ve done a little more digging and as far as I can tell the variable should be set correctly automatically. Do you have the file /etc/profile.d/flatpak.sh on your system, and does it look like this?
# cat /etc/profile.d/flatpak.sh
if command -v flatpak > /dev/null; then
# set XDG_DATA_DIRS to include Flatpak installations
new_dirs=$(
(
unset G_MESSAGES_DEBUG
echo "${XDG_DATA_HOME:-"$HOME/.local/share"}/flatpak"
GIO_USE_VFS=local flatpak --installations
) | (
new_dirs=
while read -r install_path
do
share_path=$install_path/exports/share
case ":$XDG_DATA_DIRS:" in
(*":$share_path:"*) :;;
(*":$share_path/:"*) :;;
(*) new_dirs=${new_dirs:+${new_dirs}:}$share_path;;
esac
done
echo "$new_dirs"
)
)
export XDG_DATA_DIRS
XDG_DATA_DIRS="${new_dirs:+${new_dirs}:}${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"
fi
The first commands sets the $XDG_DATA_DIRS variable to what it should be for root, and the second command reloads the /root/.bashrc file. You can then try running the flatpak update command again.
That’s fixing the symptom, not the cause. For instance, /root/.local/share/flatpak/exports/share looks to be a user-wide flatpak installation for user root which can’t be updated with sudo (sudo flatpak --user update fails), it requires su. Generally we have a system-wide installation at /var/lib/flatpak or a user-wide installation at $HOME/.local/share/flatpak/exports/share.
That looks fine. Which user do you use to run flatpak update? If root, which method do you use to get a root shell? If possible illustrate with the actual commands you run.
$ su
Password:
# flatpak update
Note that the directory
'/root/.local/share/flatpak/exports/share'
is not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.
Looking for updates…
Nothing to do.
# exit
$ su -
Password:
# flatpak update
Looking for updates…
Nothing to do.
Notice the issue appears when running just su which can lead to a weird environment. No idea if there’s a reasonable use case for this. So if that’s what you doing, always run with su -.
I couldn’t replicate the issue with sudo (even though XDG_DATA_DIRS might be unset) but it could lead to same depending on your system local configuration. If you end up with this with sudo then please share your modified sudoers configuration.
(Remember to undo your changes to /root/.bashrc which only treated the symptom)
If you want to avoid this issues altogether, you can run flatpak update with your regular user:
move your system flathub remote to a user one, or
add your regular user to the wheel group (this adds privilege to your user)