CentOS 8 snapd install of Authy doesn't show up in applications folder

I have Authy installed on CentOS 8 and latest Fedora. Fedora works as expected, but CentOS does not. When I install in CentOS I get

$ sudo snap install authy --beta
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you’ve not restarted your session
since you installed snapd, try doing that. Please see How to fix snap binaries not found
for more details.

authy (beta) 1.8.0 from Authy (authy-twilio) installed
$ echo $PATH

$ snap version
snap 2.43.3-1.el8
snapd 2.43.3-1.el8
series 16
centos 8
kernel 4.18.0-187.el8.x86_64

NAME=“CentOS Linux”
VERSION=“8 (Core)”
ID_LIKE=“rhel fedora”
PRETTY_NAME=“CentOS Linux 8 (Core)”


OS: CentOS Linux 8 (Core) x86_64
Host: OptiPlex 9020 01
Kernel: 4.18.0-187.el8.x86_64
Uptime: 1 day, 10 hours, 4 mins
Packages: 1608 (rpm), 24 (flatpak), 6 (snap)
Shell: bash 4.4.19
Resolution: 1920x1080
Terminal: /dev/pts/0
CPU: Intel i7-4790 (8) @ 4.000GHz
GPU: Intel HD Graphics
GPU: NVIDIA GeForce GT 640
Memory: 6215MiB / 15781MiB

The install seems to have worked, I can execute Authy from the command line. Problem is, the application doesn’t show in the application folder and when it does execute it shows a “broken” icon on the panel. I am unable to add it to favorites or launch the application by any other means.

I’d appreciate any help.

Have you restarted your graphical session?

Yes, I’ve restarted the entire system. I also had the browser extension (and browser application) installed prior to the desktop application. I’ve since uninstalled both of those, performed removal of authy snap then reinstalled and restarted. I still do not have anything in my applications.

Launching authy from terminal starts the application with the below terminal output.

$ authy
Gtk-Message: 08:10:10.277: Failed to load module “pk-gtk-module”
Gtk-Message: 08:10:10.281: Failed to load module “pk-gtk-module”
TypeError: Cannot read property ‘then’ of undefined
at Function.AutoUpdater.init (/snap/authy/1/resources/app.asar/js/background.js:63011:22)
at Object.create (/snap/authy/1/resources/app.asar/js/background.js:56805:34)
at App.WindowHelper.create (/snap/authy/1/resources/app.asar/js/background.js:13678:32)
at App.emit (events.js:208:15)
[8591:0417/081010.613114:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command

and Screenshot showing the “icon” (right-most icon) for running Authy Instance


I also attempted a clean installation today, the snap installs but does not put the application in the folder with the other applications. I was able to install the chrome app (not extension) and it shows in my applications and I can add that to favorites to launch more conveniently than command line. But I still get the notice at the top that the chrome app is not supported.

To make this more frustrating, after wiping and reinstalling my system now when I attempt to open the desktop app from command line I am unable to finish setting it up. It freezes looking up the country.


Add to this, also attempted to install signal-desktop snap - same result as with Authy. Install completes but does not leave apps in launcher and have to execute via command line. Signal was working prior to the OS reinstall.

For the install of each I saw -

$ sudo snap install signal-desktop
2020-04-20T21:51:48-07:00 INFO Waiting for restart…
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you’ve not restarted your session
since you installed snapd, try doing that. Please see How to fix snap binaries not found
for more details.

signal-desktop 1.33.1 from Snapcrafters installed
$ sudo snap install authy
error: snap “authy” is not available on stable but is available to install on the following

   beta       snap install --beta authy
   edge       snap install --edge authy

   Please be mindful pre-release channels may include features not completely tested or
   implemented. Get more information with 'snap info authy'.

$ sudo snap install authy --beta
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you’ve not restarted your session
since you installed snapd, try doing that. Please see How to fix snap binaries not found
for more details.

authy (beta) 1.8.0 from Authy (authy-twilio) installed


Outside of this, I don’t know what else I can provide to help figure this out but will provide whatever I can. Thanks for the assistance.

I was able to get this working by executing the following

$ ln -s /var/lib/snapd/desktop/applications/authy_authy.desktop ./authy_authy.desktop
$ ln -s /var/lib/snapd/desktop/applications/signal-desktop_signal-desktop.desktop ./signal-desktop_signal-desktop.desktop

This has allowed both applications to execute as expected and show in the application launch as expected. I don’t know what I could have done wrong to require manual steps here. Initially, I did not have an issue with Signal, only Authy. After a clean install I had issue with both. I’ve not attempted further snap installs, but have no reason to expect different results at this point. What can I do to narrow this down and resolve it so I don’t continue to have issues?

I don’t think you have done anything wrong. The workaround that you did shows that XDG_DATA_DIRS as seen in GNOME shell process, does not contain the /var/lib/snapd/desktop path.

There is a systemd mechanism to add environment settings during user session startup, but for some reason it does not work in your system. What is the systemd version in your system? Try running rpm -qa systemd\*.
Then please collect the output of systemctl --user show-environment | grep '^XDG_DATA_DIRS'.

If you’re using GNOME shell, you can try opening the gnome shell debugger, try Alt+F2, type lg. In the debugger run GLib.getenv("XDG_DATA_DIRS").

I’ve tried both CentOS8 and RHEL8, with combinations of GNOME shell/classic sessions, on x11 and wayland. Also tried directly logging in followed by startx or dbus-run-session. In each of the tries, the icon showed up and XDG_DATA_DIRS was set correctly. I’m using snapd version 2.43.3-1.el8.

Please double check that /usr/lib/environment.d/990-snapd.conf is present. You can try and add some variable there, eg. FOO=1, then restart the session and verify that it’s really set. If it is, there’s perhaps something else overriding the XDG_DATA_DIRS environment variable.

This is the output of the items you asked for.

$ rpm -qa systemd*
$ systemctl --user show-environment | grep ‘^XDG_DATA_DIRS’

is present and contains


As for adding something to 990-snapd.conf, I tried that and then Alt+F2 ‘r’ and the entry I added persisted. Is that adequate to restart the session or do I need to fully log out?

I think you need to log out and log back in. The entry you add should appear in your environment, visible in systemctl show-environment, lg and terminal.

After editing /usr/lib/environment.d/990-snapd.conf

$ cat /usr/lib/environment.d/990-snapd.conf

Tested with logout/login as well as full restart. The following is what I showed following logout/login as well as restart.

$ cat /usr/lib/environment.d/990-snapd.conf

$ systemctl show-environment

This is supposed to be systemctl --user show-environment. Is FOO=1 listed there?

My mistake, yes, FOO is listed when I enter the correct command.

Then clearly the user env generator runs. There must be something else that runs after that overwrites XDG_DATA_DIRS instead of (ap-|pre-)pending.

I see there’s this file:

$ cat /usr/share/gdm/env.d/flatpak.env 

which I think is run by gdm at some point. Though I have no idea why it does not seem to be a problem in my system.

Perhaps someone more familiar with the desktop session stack can help, cc @jamesh @kenvandine

If anything, maybe you actually need to file a bug in CentOS bug tracker.

If file /usr/share/gdm/env.d/flatpak.env is indeed the problem, then it would be a Flatpak bug, upstream of CentOS:

Now I cannot tell why /usr/share/gdm/env.d/flatpak.env (used by the Gnome Wayland graphical sessions) would be taken into account, or taken into account after and overwrite /usr/lib/environment.d/990-snapd.conf (used by systemd) in some cases and not others. Perhaps it is related to the version of Gnome and traditional vs. Wayland session startups:

@var38 What are the contents of the following directories?


@var38 Are you using an X11 or Wayland graphical session? See:
How to know whether Wayland or X11 is being used
Ubuntu 20.04 opens X11 sessions by default and it works pretty well as both Flatpak and Snapcraft paths appear in XDG_DATA_DIRS:

$ loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type
$ ls -l /usr/lib/environment.d
total 4
lrwxrwxrwx 1 root root  16 Apr 14 00:05 99-environment.conf -> /etc/environment
-rw-r--r-- 1 root root 106 Apr 10 16:57 990-snapd.conf
$ ls -l /usr/share/gdm/env.d
total 4
-rw-r--r-- 1 root root 118 Mar 31 12:56 flatpak.env

It still works after switching to Wayland:

$ loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type

Perhaps it’s different in CentOS.

$ ls /usr/share/gdm/env.d/
$ ls /usr/lib/environment.d/
990-snapd.conf 99-environment.conf

If flatpak.env is only used for Wayland is that something that can just be removed? As far as I know, I’m not running Wayland unless that changed when I reinstalled the other day. If I recall, the video card I’m using isn’t supported by Wayland so it’s not an option. Also, only have a few apps from flatpak - is that something that could be uninstalled or just the .env removed as a test?

I wouldn’t remove Flatpak for now. Perhaps temporarily move /usr/share/gdm/env.d/flatpak.env out of the way, for example:

sudo mv /usr/share/gdm/env.d/flatpak.env /

Then close and reopen your graphical session or better yet reboot. Does it help? What is the output of echo $XDG_DATA_DIRS? If it does help, we will still have to understand why this occurs on your CentOS machine but not your Fedora machine or my Ubuntu workstation. My gut feeling is that it is a Flatpak bug as it seems to be overwriting XDG_DATA_DIRS instead of adding to it:


Compare with 990-snapd.conf which adds to XDG_DATA_DIRS instead of overwriting it:


To restore the Flatpak file:

sudo mv /flatpak.env /usr/share/gdm/env.d/

moved flatpak.env, restarted system and it doesn’t appear to have changed

And realized I missed some of what you put in you last post regarding x11, follows

$ cat /usr/lib/environment.d/990-snapd.conf
$ loginctl show-session $(awk ‘/tty/ {print $1}’ <(loginctl)) -p Type
$ ls -l /usr/lib/environment.d
total 4
-rw-r–r--. 1 root root 120 Apr 21 14:15 990-snapd.conf
lrwxrwxrwx. 1 root root 24 Apr 9 14:52 99-environment.conf -> …/…/…/etc/environment

Perhaps not a Flatpak issue then. But then please use systemctl --user show-environment instead of echo $XDG_DATA_DIRS . See below.

Reading your posts again, I am a little bit lost because symptoms keep changing. In your first post $PATH is correctly set, at least in the shell:

Then you reinstalled CentOS 8 and different problems appeared. Yet $XDG_DATA_DIRS is correctly set, at least in the shell:

Then /var/lib/snapd/desktop is missing from $XDG_DATA_DIRS but this time from systemctl --user show-environment:

Environment variables might be different in a shell environment and in the graphical session environment. That’s why you should use systemctl --user show-environment.

In my case:

$ echo $PATH 
$ systemctl --user show-environment | grep '^PATH'
$ echo $XDG_DATA_DIRS 
$ systemctl --user show-environment | grep '^XDG_DATA_DIRS'
$ flatpak list
$ snap list 
Name                 Version                     Rev   Tracking         Publisher             Notes
authy                1.8.0                       1     latest/beta      authy-twilio          -
canonical-livepatch  9.5.5                       95    latest/stable    canonical*            -
core                 16-2.44.3                   9066  latest/stable    canonical*            core
core18               20200311                    1705  latest/stable    canonical*            base
gnome-3-28-1804      3.28.0-16-g27c9498.27c9498  116   latest/stable    canonical*            -
gtk-common-themes    0.1-36-gc75f853             1506  latest/stable    canonical*            -
multipass            1.1.0                       1784  latest/stable    canonical*            classic
openfortivpn         1.13.3+git29.ga53d037       24    latest/beta      dimitri-papadopoulos  -
slack                4.4.2                       23    latest/stable    slack*                classic
snap-store           3.36.0-74-ga164ec9          433   latest/stable/…  canonical*            -
snapcraft            3.11                        4282  latest/stable    canonical*            classic
$ /snap/bin/authy


Perhaps you can do the same on your CentOS machine to recap the problem at hand? With and without /usr/share/gdm/env.d/flatpak.env and always after a reboot to be on the safe side?