I’m having an intermittent issue where my flatpak software is not recognized by Thunar. For instance, I have LibreOffice installed as a flatpak and set Writer as the default app for *.odt files, but sometimes, if I right-click on this file type, it doesn’t appear as an option:
Checking the “Set Default Application” menu shows that LibreOffice Writer is missing from there, too:
Double-clicking the file causes it to open in whatever app Thunar has decided is the new default (such as the archive manager in the screenshot above).
As mentioned, this issue is intermittent, so it often goes away after rebooting my machine. In the meantime, I can also open my flatpak applications other ways, such as double-clicking on the desktop or Whisker menu icons or running a terminal command.
I’m on Xubuntu 25.04, xfdesktop version 4.20.1, running on Xfce 4.20 with X11 and Thunar 4.20.2.
Any differences in Thunar’s environment variables between when it works and when the problem is occuring?
See here for how to get the environment variables of the running Thunar process (although reading the /proc/<PID>/environ file may require root/sudo even when your user owns the process)
Hmm. To confirm that this really is not an issue with environment variables, please post the output from running the following command in Terminal -
env | grep -i flatpak
(If the output contains paths inside /home/XXXX/... and the XXXX for you matches output of whoami, feel free to obscure your local username if you want.)
Is LibreOffice installed in the system flatpak installation (usually /var/lib/flatpak) or the user flatpak installation (usually ~/.local/share/flatpak)?
When the issue occurs, does
journalctl -b | grep -i apparmor
output anything related to Thunar, LibreOffice, or flatpak?
More generally, when the issue occurs do you see any relevant output when paging through journalctl -b output from between when you know for sure it was working and when the issue started?
Did the flatpak installation for LO drop .desktop files for the various components in /usr/share/applications/ or ~/.local/share/applications/ ? The older version of LO available from the repositories through apt does, and those .desktop-files have a line with all the MimeTypes the program(s) can open.
There’s also ~/.config/mimeapps.list which stores associations between MimeTypes and programs.
Either of those should at least reduce the problem …
Good news! I think I’ve isolated the source of the problem using the suggestions you gave me, although I’m not quite sure why this problem exists.
I frequently have a drive mounted for work, and I have a script that does the mounting and opens up the drive for my perusal, which looks like this:
if [ -z "$SUDO_COMMAND" ]; then
exec sudo "$0" "$1"
fi
mount -t cifs -o username=XXXXX@YYY.ZZZ,uid=1000,gid=1000 /path/to/remote /path/to/mount/point
if [ $? == 0 ]; then
sudo -u XXXXX bash -c "thunar \"/path/to/mount/point\" & disown"
fi
If I comment that line out, then the drive mounts, and flatpaks still work in Thunar. If I run it WITH the line, then the drive mounts and the folder opens, but flatpaks are now broken. Once I unmount the drive and restart Thunar, flatpaks start working again.
Now, what confuses me is WHY that line would cause flatpaks to break, especially since I’m pretty sure this wasn’t a problem before I upgraded to Xubuntu 25.04. The only line related to this in journalctl (and what clued me in) is the following:
If it’s not differences in environment then I have no idea why that line would cause that, sorry. My only thought would be to try refactoring your script something like this, if this way would get the result you need:
sudo mount -t cifs -o username=XXXXX@YYY.ZZZ,uid=1000,gid=1000 /path/to/remote /path/to/mount/point
if [ $? == 0 ]; then
exo-open "/path/to/mount/point"
fi
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their existing environment
variables. The security policy may return an error if the user does not have permission to pre‐
serve the environment.
Try adding -E to your sudo call that fires up thunar and see if that changes anything …
Removing the sudo -u causes Thunar to open as root, which I want to avoid. sudo -u XXXXX bash -c 'exo-open "/path/to/mount/point"' also breaks flatpaks.
It seems to be related to the sudo -u XXXXX piece. If I try to run the rest of the command without it, everything works fine, but again, it causes Thunar to open as root in the script, since the script is run as root to allow mounting.
It makes me wonder if this is an XFCE/Thunar bug. I’ll open a ticket.
That did it! I’m guessing the environment variable values that reference the path for flatpaks aren’t preserved when I do sudo -u XXXXX, but sudo -E -u XXXXX fixes the problem.
Either there was a security policy change since Xubuntu 22.04 (my last version) that doesn’t allow this by default, or I had that version of Xubuntu set up differently. (My “upgrade” was a wipe and reinstall.)
I spoke too soon. It worked from the command line, but when I put the line sudo -u XXXXX -E exo-open "/path/to/mount/point" in the script, Thunar now opens as if it was root (although without the warning that I’m running as root). This makes me think the -E flag is importing root’s environment variables, not the user’s.
If that XXXXX is the user you’re logged in as, why run the entire script as root? You can call sudo within your script so that only the mount command runs as root, and let the rest run as your regular user in the normal context of your logged-in session.
Sorry I wasn’t clear about the reasons for the suggested refactoring.
Because I wanted to add the script to /etc/sudoers.d so that I could mount the drive without having to type in the root password, but I could only get it to work if I set up the script to run as root. I also didn’t want to affect the entire mount command, only its use in this script.
No apologies necessary. I’ve always found /etc/sudoers.d a bit baffling, so it’s possible I overlooked a simpler way to set things up.
Have you considered using gio mount smb://<remote ip>/ instead ? Or do you need it mounted outside of your user session (gio mount uses gfvs and the mounted dir should just show up in thunar in your session)
I wasn’t aware of it but just gave it a try. I can mount using it, although it breaks some of the other scripts I use that rely on the existing mount path. I also feel it’s a touch slower than the current mount.
It is possible to configure sudoers so that only that specificmount command can be run without a password, but running any other mount command or supplying any other arguments requires a password. Although this would also make it possible to copy+paste the exact mount command from your script and run it without a password in a Terminal outside of the script. Would that be sufficient?
Given that changing sudoers is highly sensitive territory, do you have access to a disposable or semi-disposable system (e.g. a snapshotted VM) where you can experiment and then replicate what worked on your production system? If not, I would suggest to back up your system before changing anything in sudoers.
Especially since some things are redacted in what you’ve posted, read man sudoers carefully to be sure you understand what character(s) need to be escaped.
Testing the following snippet in Xubuntu 22.04, using visudo with new file in /etc/sudoers.d, it seems to work:
But you might consider waiting for someone else to review this sudoers snippet if you cannot test it in a disposable environment, I’m not an expert in sudoers either.
Another solution that worked for me was changing the script alias from
alias myAlias='/path/to/script'
to
alias myAlias='/path/to/script && exo-open "/path/to/mount/point"'
This allows the script to be run as root but the folder to be opened as the user. I think I’ll go with this for now. I may still file that bug report, since it does seem that the behavior of sudo -u has changed.
