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

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.