Classic snap launcher script is broken on Ubuntu 26.04 LTS

[jnsgruk]

Hi there

I recently upgraded to Ubuntu 26.04 LTS, and the Obsidian snap stopped working. After some investigation with colleagues, it seems this is due to a divergent behaviour in rust-coreutils and a (potentially incorrect?) script that is packaged in the snap by Electron builder.

The issue in this snap is /snap/obsidian/current/desktop-common.sh:

function can_open_file() {
  head -c0 "$1" &> /dev/null
}
...
if can_open_file "$REALHOME/.config/user-dirs.dirs" && can_open_file "$REALHOME/.config/user-dirs.locale"; then
...
# Create links for user-dirs.dirs
if [ $needs_xdg_links = true ]; then
  for ((i = 0; i < ${#XDG_SPECIAL_DIRS_PATHS[@]}; i++)); do
    b="$(realpath "${XDG_SPECIAL_DIRS_PATHS[$i]}" --relative-to="$HOME")"
    if [ -e "$REALHOME/$b" ]; then
      if [ -d "$HOME/$b" ]; then
        rmdir "$HOME/$b" 2> /dev/null
      fi
...

Basically trying to replace XDG directories for the snap by symlink to the real dir. In that case it’s a classic snap so it shouldn’t try to do that but

$ gnuhead -c0 ~/Documents; echo $?
0
$ head -c0 ~/Documents; echo $?
head: error reading '/home/ubuntu/Documents': Is a directory
1

The head behavior is different in rust-coreutils which makes the check it does to decide if it needs to do the symlink dance or not fail and try to rmdir ~/Documents and errors out

That launcher script appears to be included as part of electron builder, and hasn’t been updated for some time.

The script seems to be in the binary release tarball but I can't find it in the source anywhere to propose a patch.

I suspect there are more snaps affected than just Obsidian

(Reference to the Obsidian forum post: https://forum.obsidian.md/t/obsidian-snap-doesnt-start-open-with-ubuntu-26-04/113569/28)

[seb128]

For reference the version of the script in https://github.com/canonical/snapcraft/blob/c97d807086d3cdd05ed5fbe189f67f6514260eb2/extensions/desktop/common/desktop-exports#L23 has

function can_open_file() { [ -f "$1" ] && [ -r "$1" ] }

[whitenoisedev]

Hello from Obsidian

I want to clarify that there are two issues at play here:

1. The script generated by electron-builder for snaps in classic confinement mode is incorrect.
   As @jnsgruk has hinted, in classic confinement, you shouldn't replace XDG directories. Perhaps, it is correct in strict mode. I believe it is not correct in classic mode. The canonical devs can chime in here.
   This has created Obsidian and other apps that use electron-builder to build classic apps
   a host of problems, the most prominent of which is the failure to use the user-selected default browser when clicking on links. See 1 2.
   This has been a long standing problem (all versions of Ubuntu, as far as I can remember).

2. The second problem is that the behavior of head has changed in Ubuntu 26.04, due to Ubuntu's switch from gnu coreutiles to rust-coreutils. This makes the can_open_file() function in the script act differently in 26.04.

[mmaietta]

The snap logic is actually coming from an upstream Go dependency app-builder-bin => scripts located here: https://github.com/develar/app-builder/tree/master/pkg/package-format/snap

Sounds like I need to revisit writing the entire logic into JS within electron-builder. Seems necessary anyhow to support the newer cores - I'll add this to my todo-list.

[jnsgruk]

That’s excellent, thank you @mmaietta!

[mmaietta]

You can follow in this PR 🙂
#9517

[mmaietta]

Out of curiosity, do any of you care about continuing usage of core18/20/22? Or can I just focus my efforts on core24? I'm migrating the older core functionality, but also might as well add direct support for core24 under a new property since snap config is getting quite complex mix-n-matching across the different core-specific support/logic that are already diverging.

My current thoughts are to focus on core24 support as part of the migration/feature-expansion:

• add a new snapcraft core property that allows separate configs for core18/20/22/24 + custom (verbatim-imported snapcraft.yaml filepath). snapcraft.base: <core number> determines which config to leverage within snapcraft
• core24 will add support for LXD, multipass, remote builds, destructive mode, and broader extensions configuration
• Migrate as much as possible to use snapcraft directly instead of using the snap "templates"/pre-built configs that the upstream app-builder-bin leverages. (which core24 can't use anyways)
• Reactivate snapHeavyTest for the new core setup. Runs within canonical Snapcraft docker images
  https://github.com/electron-userland/electron-builder/pull/9517/changes#diff-834cb3ce8709f00a72e4ee879532ae94951c8e1b389e6c8f0107c9e15e69617bR79-R98

Something like:

/// in Configuration root
{
   ...
   snap: SnapOptions // legacy/current config and tsdoc-marked deprecated. will be superseded by `snapcraft` property
   snapcraft: SnapcraftOptions
   ...
}

// separately
export interface SnapcraftOptions extends TargetSpecificOptions {
  /**
   * A snap of type base to be used as the execution environment for this snap. Examples: `core18`, `core20`, `core22`, `core24`.
   */
  readonly base: "core18" | "core20" | "core22" | "core24" | "custom"
  readonly core18?: SnapOptions | null
  readonly core20?: SnapOptions | null
  readonly core22?: SnapOptions | null
  readonly core24?: SnapOptions24 | null
  /**
   * Pass-through custom snap configuration. electron-builder will read the
   * snapcraft.yaml at `yamlPath` and use it verbatim — no plugs, extensions,
   * organize mappings, or desktop files are injected.
   */
  readonly custom?: SnapOptionsCustom | null
}

What are your thoughts?

[jnsgruk]

Theoretically any snap built for the previous bases should will work with core24 - there might be minor behaviour differences but in general having electron-builder be more aggressive about moving the base forward as we release new LTS releases is probably better for the Snaps - they'll benefit from newer extensions, better desktop integration etc.

I don't know enough about the usage of electron builder to know how this would affect the projects using it though

[jnsgruk]

Don't know whether it's useful, but the "official" jsonschema if which options are supported with which base is here: https://github.com/canonical/snapcraft/blob/main/schema/snapcraft.json

[mmaietta]

Thanks for the suggestion and pointer! Got that already set up 🙂
https://github.com/electron-userland/electron-builder/pull/9517/changes#diff-0baa5befc66d616e41ff59a1528e71325c3639dc89118813d4ef37f7134f4943

The core24 will be opt-in. No aggressive moving the base forward for v26. For v27, I plan to bump it to the modern package.

[whitenoisedev]

From my limited experience we just used core20 when we first configured the snap and never touched it.

[jnsgruk]

There is also core26 in stable as of this week. There are no major schema changes though, so your core24 implementation should be compatible.

https://documentation.ubuntu.com/snapcraft/latest/release-notes/snapcraft-9-0/

https://documentation.ubuntu.com/snapcraft/latest/how-to/change-bases/change-from-core24-to-core26/

[jnsgruk]

Ah, though I hear we're still polishing the desktop content snaps, so perhaps we should stick with core24 for now.

[mmaietta]

Nice w.r.t core26! I actually was already placing in some logic to allow future support/scalability for new cores as they're released.

I'm adding in a SnapOptionsCustom config property whose primary purpose is to allow passing in a snapcraft.yaml file that is then utilized by electron-builder - ideally verbatim, no edits made.
That being said, are there YAML properties that could be inserted automatically and/or validated? (I'll also research this, but curious if you already have some pointers.)

Current proposed code:

export interface SnapcraftOptions extends TargetSpecificOptions {
  /**
   * A snap of type base to be used as the execution environment for this snap. Examples: `core18`, `core20`, `core22`, `core24`.
   */
  readonly base: "core18" | "core20" | "core22" | "core24" | "custom"
  readonly core18?: SnapOptions | null
  readonly core20?: SnapOptions | null
  readonly core22?: SnapOptions | null
  readonly core24?: SnapOptions24 | null
  /**
   * Pass-through custom snap configuration. electron-builder will read the
   * snapcraft.yaml at `yamlPath` and use it verbatim — no plugs, extensions,
   * organize mappings, or desktop files are injected.
   */
  readonly custom?: SnapOptionsCustom | null
}


export interface SnapOptionsCustom {
  /**
   * Path to an existing `snapcraft.yaml` file, relative to `buildResourcesDir`.
   * electron-builder reads the file and passes it through without modification.
   */
  readonly yamlPath?: string | null
}

[jnsgruk]

I'm not sure that automatically including things in an manually provided snapcraft.yaml is the right thing to do, but if the builder has the ability to warn, then it might be worth checking for the following:

• setting compression: lzo as a top-level attribute - this should really be the default for electron snaps I think
• (for strict snaps only) for core24, inclusion of the gnome extension in the apps section of the snapcraft
• (for strict snaps only) in core24 this gpu-2404 part can be used verbatim in pretty much all core24 snaps and it'll sort the wiring of the gpu bits
• similarly, almost all electron snaps I look after set this

One thing that I think would be really helpful, is when the user is not manually providing the snapcraft, for electron builder to output the YAML it is using at higher verbosity levels, which could help users see what's happening, and perhaps then use that for troubleshooting with manual adjustments using snapcraft?

@kenvandine - do you have any opinions here?