"No such file or directory" on musl libc Linux distributions when escaping the Flatpak sandbox

[rudolf-enum]

EDIT: The original text of this issue assumes that this Flatpak of Zed doesn't escape the Flatpak sandbox, which it does, and so it's like running zed directly, which in this case doesn't work as Zed is dynamically linked against glibc.

---

Hello, I'm having trouble running this on Alpine Linux -- though I assume that the choice of distro shouldn't matter too much since it's flatpak.

Zed doesn't even start, flatpak run dev.zed.Zed immediately fails to launch the binary.

$ flatpak run dev.zed.Zed
Portal call failed: Failed to start command: Failed to execute child process “/var/lib/flatpak/app/dev.zed.Zed/x86_64/stable/29feaf6558a8c888be0fba1f474731bb7775cee82c1dfd126e724122c643e3e7/files/bin/zed” (No such file or directory)

The file is there, but I can't run it directly (outside of flatpak) because Alpine has musl instead of glibc and the Linux release of Zed is dynamically linked to glibc.

$ /var/lib/flatpak/app/dev.zed.Zed/x86_64/stable/29feaf6558a8c888be0fba1f474731bb7775cee82c1dfd126e724122c643e3e7/files/bin/zed
exec: Failed to execute process '/var/lib/flatpak/app/dev.zed.Zed/x86_64/stable/29feaf6558a8c888be0fba1f474731bb7775cee82c1dfd126e724122c643e3e7/files/bin/zed': The file exists and is executable. Check the interpreter or linker?

There is a seemingly relevant open issue in Flatpak itself where the OS is NixOS, which tends to share with Alpine these kinds of issues.

Since I don't have issues with any other Flatpak package, could it be that the issue is with dev.zed.Zed? Thank you.

[rudolf-enum]

Just found this note on the Zed website which could explain this.

Source

[ShobuPrime]

Another thing to consider regarding the sandbox from @someone13574's comment:

There is a environment variable, ZED_FLATPAK_NO_ESCAPE, that disables the sandbox escape if set to anything, causing the app to be launched from inside the sandbox.

Let us know if staying within the sandbox works for you

[rudolf-enum]

That worked, thanks @ShobuPrime . Though as expected, the things listed in the comment simply don't work -- e.g. the terminal, which seems to be some sort of a Flatpak /bin/sh shell.

$ flatpak override dev.zed.Zed --env=ZED_FLATPAK_NO_ESCAPE=true --user

$ flatpak run dev.zed.Zed

[vixalien]

I was having the same issue and passing ZED_FLATPAK_NO_ESCAPE=1 as an env var fixed it.

doing an ldd on zed, it turns out that it requires glibc, which I don't have on my alpine system. I think escaping the flatpak sandbox misses the entire point of flatpak, and maybe this flag can be added as default in this project.

[Erven2016]

I also had this issue in NixOS, but your method solved my problem.

That worked, thanks @ShobuPrime . Though as expected, the things listed in the comment simply don't work -- e.g. the terminal, which seems to be some sort of a Flatpak /bin/sh shell.

$ flatpak override dev.zed.Zed --env=ZED_FLATPAK_NO_ESCAPE=true --user

$ flatpak run dev.zed.Zed

[rudolf-enum]

Come to think of it, wouldn't it be possible to specifically re-include the org.freedesktop.Sdk-bundled libs so that musl libc users can run it without the ESCAPE? I'm assuming that's the only thing preventing it from running.

I tried the following without success, but that could be just my lack of understanding of how LD_LIBRARY_PATH works.

flatpak override --user dev.zed.Zed --env=LD_LIBRARY_PATH="/var/lib/flatpak/runtime/org.freedesktop.Sdk/x86_64/23.08/be4a045f86be2b8a7a592bab299c7dd41c174eba94ab804
8401b1fa01c9eb86a/files/lib/x86_64-linux-gnu/"

[rudolf-enum]

Oh, nevermind, the LD_LIBRARY_PATH can be modified directly inside Zed too (it's defined together with the NO_ESCAPE var), however no matter what I set it to, the problem is still the same.

$ flatpak run --verbose dev.zed.Zed
[redacted]
F: Running 'bwrap --args 37 -- zed'
Portal call failed: Failed to start command: Failed to execute child process “/var/lib/flatpak/app/dev.zed.Zed/x86_64/stable/dc4752dc5761f9d27856381519f381170580c99c6bc020aad980cea8efe18378/files/bin/zed” (No such file or directory)

It seems that the issue is not with the bundled libs.

[vixalien]

So I think the current best approach if you want (or need) to use Zed without the sandbox escape is to enable the ZED_FLATPAK_NO_ESCAPE=1 variable, and then add the following to user settings:

{
  "terminal": {
    "shell": {
      "with_arguments": {
        "program": "flatpak-spawn",
        "args": ["--host", "--env=TERM=xterm-256color", "bash"]
      }
    }
  }

This will enable the terminal to launch as if it was on the host.

This was adapted from VSCode. It would be better if host-spawn was bundled together with the app though.

[someone13574]

It would be better if host-spawn was bundled together with the app though.

That’s what I was doing in some earlier prototypes of flatpak support, but the Zed developers were against having a third party program as a critical part. Not sure if it not being the primary method changes anything.

[vixalien]

but the Zed developers were against having a third party program as a critical part.

Sure, but adding a sandbox escape is a worse idea tbh.

[rudolf-enum]

Thought of a workaround for us musl users. The Zed remote server is statically linked and it will run on (almost) any system, so we can run Zed itself sandboxed and remote into localhost.

Install and run the OpenSSH server (or Dropbear + OpenSSH SFTP) and add your SSH public key to your own authorized_keys file. Then in Zed open the remotes menu and connect to yourusername@localhost. It'll download the server binary into ~/.zed_server.

An example from my Alpine machine, sans any security for the SSH server:

# apk add dropbear openssh-sftp-server
# rc-update add dropbear
# rc-service dropbear start
$ ssh-keygen
$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
$ flatpak install dev.zed.Zed
$ flatpak override dev.zed.Zed --env=ZED_FLATPAK_NO_ESCAPE=true --user
$ flatpak run dev.zed.Zed --foreground
...
ssh yourusername@localhost

[jerome-benoit]

@rudolf-enum: you should refine the issue title to something more meaningful explicitly mentioning zed flatpak and musl distros support issues.