/usr/share/void/void: 没有那个文件或目录（There is no such file or directory）

[qcr10nrh]

$ ./Void-1.2.0.25104.glibc2.29-x86_64.AppImage
/tmp/.mount_Void-1uHf7bU/AppRun:行10: /usr/share/void/void: 没有那个文件或目录（There is no such file or directory）

[nordwestt]

To add a bit of context to this, since I'm experiencing the same problem:

This happens when you download the Linux AppImage and try to execute it

Personally, I'm getting: "/tmp/.mount_void.AbW1irp/AppRun: line 10: /usr/share/void/void: No such file or directory"

[zhangchunlin]

My error in ubuntu 24.04:

$ ./Void-1.2.1.25105.glibc2.29-x86_64.AppImage 
sed: /tmp/.mount_Void-1a1vSLA/lib/x86_64-linux-gnu/libselinux.so.1: no version information available (required by sed)
/tmp/.mount_Void-1a1vSLA/AppRun: 10: exec: /usr/share/void/void: not found

[andrewpareles]

Can you try again with the latest version? @qcr10nrh @nordwestt @zhangchunlin If AppImage is still broken (even in the latest version), then can you also try with the tar.gz available here? https://github.com/voideditor/binaries/releases

Not sure why AppImage is breaking - maybe it only works on Ubuntu 22.04+? Let me know if the tar files work for you!

[zhangchunlin]

In ubuntu24.04 have other error:

$ ./Void-1.99.30003.glibc2.29-x86_64.AppImage 
sed: /tmp/.mount_Void-1II8sq3/lib/x86_64-linux-gnu/libselinux.so.1: no version information available (required by sed)
/tmp/.mount_Void-1II8sq3/AppRun: 10: exec: /usr/share/void/void: not found

[jfpedroza]

Also getting the error on Endeavour OS.

$ ./Void-1.99.30003.glibc2.29-x86_64_0b7060dfd8b759f56ff3c204c74b0776.AppImage
/tmp/.mount_Void-1oiXXJ2/AppRun: line 10: /usr/share/void/void: No such file or directory

The .tar.gz works.

[andrewpareles]

I think we'll start giving people the .tar.gz files instead. Seems to work for a lot more folks. Thanks for sharing.

[zhangchunlin]

For .tar.gz have this error:

~/opt/voideditor/Void-linux-x64-1.99.30003$ ./void 
[577745:0504/223137.194312:FATAL:setuid_sandbox_host.cc(163)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /home/zhangclb/opt/voideditor/Void-linux-x64-1.99.30003/chrome-sandbox is owned by root and has mode 4755.
追踪或断点陷阱 (核心已转储)

[Nao-30]

@andrewpareles i think it's related to the updates following the release of Ubuntu 23.##~

Ubuntu 24.04 implements a stricter security model through AppArmor that specifically targets unprivileged user namespaces2.

you can review the full article

For a complete understanding of this issue, including technical details, implementation specifics, you can take a look at:

• Technical Deep Dive

For a more direct practical solutions, you can take a look at:

• Practical Workarounds

pretty sure they'll be helpfull

[andrewpareles]

Thanks a lot @Nao-30. Does this only apply to AppImage (is that why the .tar.gz's still work?)

[lnxyz]

$ ./Void-1.2.0.25104.glibc2.29-x86_64.AppImage /tmp/.mount_Void-1uHf7bU/AppRun:行10: /usr/share/void/void: 没有那个文件或目录（There is no such file or directory）

My error in ubuntu 24.04:

$ ./Void-1.2.1.25105.glibc2.29-x86_64.AppImage 
sed: /tmp/.mount_Void-1a1vSLA/lib/x86_64-linux-gnu/libselinux.so.1: no version information available (required by sed)
/tmp/.mount_Void-1a1vSLA/AppRun: 10: exec: /usr/share/void/void: not found

change AppRun EXEC variable
EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g') to EXEC="${HERE}"/usr/share/void/void ， will solve it.

采用 ./Void-1.2.0.25104.glibc2.29-x86_64.AppImage --appimage-extract 解包，
修改 squashfs-root/ AppRun内容，
然后再重新打包 appimagetool squashfs-root/ void-x86_64.AppImage 就可以了。
@qcr10nrh @zhangchunlin

[Nao-30]

Thanks a lot @Nao-30. Does this only apply to AppImage (is that why the .tar.gz's still work?)

You're welcome! @andrewpareles

and Yes, correct, and if someone faced it it's still fixable,

The issue happens because AppImages are FUSE-mounted with nosuid, this prevents any set-UID helper from running~

Ubuntu’s default AppArmor policy also disallows unprivileged user namespaces

so now as mentioned the AppImage can use neither the kernel userns nor the setuid sandbox. In short, on Ubuntu 23.++ an electron AppImage is trapped: it's chrome-sandbox can’t be made set-UID on the FUSE mount, and userns is blocked (unless you add a custom AppArmor profile to allow it as mentioned in the blog based on askubuntu.com).

By contrast, the .tar.gz release is simply unpacked onto a normal filesystem (e.g. /opt/void). This means its chrome-sandbox binary is on an ordinary ext4 (or similar) partition, not under a FUSE nosuid mount. A packager or user can then run:

sudo chown root:root /opt/void/chrome-sandbox 
sudo chmod 4755 /opt/void/chrome-sandbox

– granting it the correct owner and set-UID bit. Once the helper is root-owned, and correct permissions are set the Chromium sandbox should run as intended. Because the tar.gz's files aren’t subject to AppImage/AppArmor quirks and stuff, the sandbox must work normally after this fix

and ofc (No special AppArmor profile is needed for the tar install, unlike the AppImage case)

[imbev]

On AlmaLinux 10 (SELinux, not AppArmor) with Void 1.99 Appimage

sed: /tmp/.mount_void.aqnXrL3/lib/x86_64-linux-gnu/libselinux.so.1: no version information available (required by sed)
/tmp/.mount_void.aqnXrL3/AppRun: line 10: /usr/share/void/void: No such file or directory