Some snaps will only launch the first time

I’ve noticed some strange behavior with a couple of snaps, namely Bitwarden (stable release) and Authy (beta release).

These snaps launch fine the first time using the system app launcher, but any subsequent attempts to launch the apps will fail. running them from the command line provides no feedback, so I’m at a loss for how to proceed. Any ideas?

I’m having these issues on my desktop with Kubuntu 20.04, but did have the same issue with Bitwarden on my laptop a while ago (stock Ubuntu 19.10).

Here’s the (lack of) CLI output, including the output of snap --version:

waljt@highwind:~$ authy
waljt@highwind:~$ snap run authy
waljt@highwind:~$ bitwarden 
waljt@highwind:~$ snap run bitwarden
waljt@highwind:~$ snap --version
snap    2.45.1
snapd   2.45.1
series  16
ubuntu  20.04
kernel  5.4.0-39-generic
1 Like

The plot thickens… I installed both of these snaps on my primary laptop (2017 model Entroware Apollo, Kubuntu 20.04) and they work perfectly.

The old laptop I had the issue on is a 2010 model Lenovo B590.

Could this be a hardware related issue? The desktop is a custom built system with AMD Ryzen and an Nvidia GPU.

The saga continues…

I installed Authy on the old Lenovo laptop (now also running Kubuntu 20.04) and have the same issue. The app runs perfectly the first time I launch it, and after that, nothing, not even any output on the command line.

I tried looking at the output of snap run with the --gdb and --strace="with-strace" flags, but I can’t make heads nor tails of it. I’d be eternally grateful if someone who knows what to look for could replicate the issue.

The anticlimax…

Turns out something about these snaps in particular doesn’t like my symlinks.

While trying to think of what my desktop and Lenovo laptop have in common, that’s different on my Entroware laptop, I realized the two machines where the issue was present both have a second hard drive in them. In both cases, I have the drive mounted at /home/waljt/DataHoard, the Music folder in my home folder, was a symlink to a folder on the second drive.

To debug I followed this procedure on my Lenovo laptop:

  • Delete the data associated with the affected snaps (Bitwarden and Authy) under ~/snap/snapname
  • Delete the symlink ~/Music and remove the line from /etc/fstab that mounts the second drive, then reboot the system
  • Launch the apps and go through their respective setup procedures.
  • Close the apps and try to launch the apps
    • They work!
  • Reboot the system and try launching the apps
    • They still work…
  • Add the line to /etc/fstab to mount the second drive at ~/DataHoard
  • Reboot and launch the apps.
    • They still work…
  • Link the folder ~/DataHoard/Music to ~/Music by dragging it across in Dolphin (KDE File Manager) and clicking Link Here in the context menu.
  • Try launching the snaps
    • Now they don’t work.

This behaviour was the same on both the Lenovo laptop and my desktop. I’m not familiar enough with snaps and snapd to really have any idea what’s causing this. It seems to be isolated to Bitwarden and Authy… I have other snaps installed on all of my systems that consistently work just fine.

I was wondering if @popey could bring this to the attention of the snap team. No need to make it a high priority, as it probably only affects a small percentage of geeks, but something funky seems to be happening in the backend that’s beyond my level of understanding. :confused:

Note: When trying to reproduce the issue, I recommend first mounting the second drive and creating the symlink before installing the snaps, as this seems to be the only time when the snaps consistently failed to launch.

snaps heavily depend on apparmor … apparmor is usually very unhappy with symlinks acrosss filesystems but handles bind monts fine. switch the links to be bind mounts and it should all work

1 Like

Thanks for the tip. I’ve set up a bind mount in fstab for my music directory. Works fine so far.


Have the same problem in OpenSuse Tumbleweed. In my case the CLI output is:

grise@localhost:~> authy
No protocol specified

(authy:21646): Gtk-WARNING **: 14:49:01.134: cannot open display: :0

But if I run:

grise@localhost:~> /snap/authy/current/authy

it works.

So, my workaround is to avoid using snap: I made an alias to invoke authy from CLI and edited the menu entry in my KDE to launch it from GUI.

I just stumbled over the same thing with an electron app I’m trying to package at the moment.

For me the issue ended up being a symlink from ~/Downloads to ~/downloads that I keep because I have an aversion to cased directories that I type often. :stuck_out_tongue:

What struck me though is that this was not a cross-filesystem symlink. Failing without any feedback on such a simple thing seems unseemingly brittle and hard to debug. Had I not found this thread here and systematically gone through the symlinks in my home directory, I would have had no chance at this.

Thanks! This problem was driving me crazy!
Adding bind-mounts for my data-folders to file /etc/fstab solved my problem!
I have Music/Videos/Pictures on a non-ssd-disc which ist mounted under /media/datadisk.

/media/datadisk/Musik /home/userx/Musik none defaults,bind 0 0
/media/datadisk/Videos /home/userx/Videos none defaults,bind 0 0
/media/datadisk/Bilder /home/userx/Bilder none defaults,bind 0 0

I have this same problem with all snaps, not only with Authy.

I tried open with path: /snap/authy/current/authy and it works.

But create alias for all apps, its very bad.

this does not run the authy snap but only the binary inside the snap path … that it launches is sheer luck, to run the authy snap you would use either snap run authy or /snap/bin/authy … running it like you do is not running it confined and makes it not use its shipped libraries

Had the same issue, with authy only starting once and then never running again, on at least two different Linux distros, Ubuntu 21.04 and Fedora 34. Also had symlinks in my home folder to a separate partition, because my root partition is small.

Deleted the symlinks (Documents, Downloads and Pictures) and replaced them with real folders and “bind mounts” that mount the same folders on the separate partition, and suddenly authy runs every time. The authy menus still have weird graphics bugs, but it runs and works.

So this would seem to confirm that cross-filesystem symlinks and apparmor are causing this issue.

This was basically impossible to troubleshoot since there was no relevant error message when running from terminal or any log output that I could ever find. No crash notification, nothing. It would just run fine the first time, then after you quit it would never run again.

Same issue here. I’ve had to remove all my links. I REALLY need them but will have to find another way.

just use bind mounts instead …

I will. I just had to put my 2c in here because getting this far has been fairly frustrating.

1 Like

it seems to only be effected by standard directories like Video, Download etc, and varies between snaps.

I had the same problem with authy 1.8.4 and found the solution before I was aware of this thread.
The problem is indeed the symlinks in your home directory.
Those directories (in my case) are mentioned in:


The file contains references to all sorts of personal data, having entries like:
pointing to your Documents.

Removing this file solves the problem.
Or have the XDG_XXXXXXXX_DIR variables point to a dummy directory.
Or comment them out.

I cannot see the need for authy to know anything about my stuff or accessing it anyway.
And then fail to run properly …
It is there to 2FA apps, that’s it.
Works fine without that knowledge.


Oh well, that worked for 17 days … Wouldn’t run at all anymore, without any feedback as to why not.
Anyways, did a
sudo snap remove --purge authy
sudo snap install authy

Current version 1.9.0
The path changed to
Did the same as in first post, and it is working again.
This erroneous behaviour should not happen.
snap should get it’s act together.
I am a long time Debian user (currently bullseye) and not used to this kind of ****


Worked for me on Ubuntu 20.04 with Todoist snap.

Commented out the lines in snap/todoist/current/.config/user-dirs.dirs and voila, todoist runs fine.

I tried getting debug logs as I had seen done in other threads to see why exactly this made a difference, but nothing about AppArmor popped up, just a bunch of file access denied messages:

sudo strace -u $USER -f -D -vv -o ./log.trace /snap/bin/todoist

Hope a patch is forthcoming to fix this frustrating regression from standard Linux / Ubuntu behavior.

Hey guys I’m happy you got the solution but It seems like I’ve not gotten to your level in these explanations. My snap apps fails to start after the first startup I’ve reset and removed the snaps 2 times now still doesn’t solve the problem a way to go about this in English not advanced science will be much appreciated. Thank you