Some snaps will only launch the first time

snapd
4

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.

5

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
6

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

3 Likes
7

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.

8

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.

9

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
10

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.

11

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

12

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.

13

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

14

just use bind mounts instead …

15

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

1 Like
16

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

17

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:

~/snap/authy/6/.config/user-dirs.dirs

The file contains references to all sorts of personal data, having entries like:
XDG_DOCUMENTS_DIR="/home/me/Documents"
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.

2 Likes
18

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
~/snap/authy/7/.config/user-dirs.dirs
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 ****

2 Likes
19

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.

20

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

21

With my fix I expect you to have some basic linux knowledge. There is not much more to explain. Find the file user-dirs.dirs somewhere in your home directory (look at the path in my situation) and remove/modify it as stated in my first post.

1 Like
22

The latest Version as of 24/04/2023 does not have the file user-dirs.dirs :frowning: Up until now modifying of that file fixed this issue.

I have one symlink that is in the same filesystem.

23

I think that means that authy is re-creating that configuration. Would you ask the authy snap maintainer about it (either not re-creating it or putting it in the persistent directory where you could delete it ~/snap/authy/common/ ) ? Another guess - commenting those values out opposed to deleting the whole file could stop recreation.