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
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
- 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
- Reboot the system and try launching the apps
- Add the line to
/etc/fstab to mount the second drive at
- Reboot and launch the apps.
- Link the folder
~/Music by dragging it across in Dolphin (KDE File Manager) and clicking Link Here in the context menu.
- Try launching the snaps
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.
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.