trouble with AppImages on *ubuntu and a stability concern

[joedefen]

• FYI, I'm on the lastest Kubuntu, and AppImages using bwrap are defeated by apparmor. But an apparmor rule is not the fix .. instead: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. Anyhow, it seems likely this will trip up many others; to help, perhaps mentioning in the AppImage troubleshooting section?
• I want the latest stable/released nvim (v10), but AM gave me: NVIM v0.11.0-dev-211+g37bf4c572. Seriously, I almost never want to be on the "night build" of any project. So, I ran "--force-latest nvim", it said, "UPDATING NVIM", then "◆ NVIM is updated, 120 seconds elapsed!". I'm not sure I'm that patient of a person to go thru this on every such app (or wish to remember to always check). Is there a "I want latest stable always" setting instead of repairing (every?) similar install?

This looks like a great project and I'll continue to kick the tires, but philosophical differences on stability may prevent me from sticking with it for the long haul. Cheers.

[Samueru-sama]

This looks like a great project and I'll continue to kick the tires, but philosophical differences on stability may prevent me from sticking with it for the long haul.

We appreciate the feedback. Looks like that --force-latest nvim that took you so long is related to an "issue" with zsync that we are trying to fix. #650

[ivan-hc]

FYI, I'm on the lastest Kubuntu, and AppImages using bwrap are defeated by apparmor. But an apparmor rule is not the fix .. instead: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. Anyhow, it seems likely this will trip up many others; to help, perhaps mentioning in the AppImage troubleshooting section?

Thanks for this feedback, I will read the article carefully to decide how to set up the Troubleshooting.

I want the latest stable/released nvim (v10), but AM gave me: NVIM v0.11.0-dev-211+g37bf4c572. Seriously, I almost never want to be on the "night build" of any project. So, I ran "--force-latest nvim", it said, "UPDATING NVIM", then "◆ NVIM is updated, 120 seconds elapsed!". I'm not sure I'm that patient of a person to go thru this on every such app (or wish to remember to always check). Is there a "I want latest stable always" setting instead of repairing (every?) similar install?

You can also use the command

am -i --force-latest $APP1 $APP2 ... $APPn

and pray that all ends well.

However, as you did and @Samueru-sama said, the option --force-latest can be done after you've installed the app.

I've just seen that a PR for nvim and nvim-nightly is opened, and to have two separated packages is to best solution... for now.

The reason almost all the scripts are pointing to a generic "releases" instead of "releases/latest" it because I don't really trust the continuity that some developers try to give to their releases.

I mean, not always we can find the AppImage format among the packages of the latest release. Sometimes there aren't even any packages for Linux, in general, and you only find one package for Windows or MacOS. It's happened to me in the past.

This is why I chose to always aim for "releases", to be sure of having at least one package delivered to the end user.

This is why you have to "pray" for "--force-latest" to work. We are not absolutely certain that the developer will provide an AppImage package, or a generic package for Linux, in the "latest" release. You might try to install a package and only install an empty directory, complete with error messages about AppImage not installed.

You have to be sure that in "latest" there is always what you are looking for. This is why with "--force-latest" I delegate this choice to you and everyone.

This looks like a great project and I'll continue to kick the tires, but philosophical differences on stability may prevent me from sticking with it for the long haul. Cheers.

@joedefen Thanks for the appreciation. I really wish I could provide the latest stable version of the programs... but for the reasons above, I had to make this choice.

You know, AppImages are self-contained packages, and other programs in TAR/ZIP archives are too. There is no package manager for portable programs, or rather... for all portable programs. And that's what my project tries to be.

If it were recognized by the GNU/Linux community, maybe I would also have more support from the developers themselves, who could not only provide me with direct links to their apps... but could write the installation scripts themselves. Would be great. But "AM" is still little known, so I do what I can to keep it as good as possible.

[ivan-hc]

FYI, I'm on the lastest Kubuntu, and AppImages using bwrap are defeated by apparmor. But an apparmor rule is not the fix .. instead: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. Anyhow, it seems likely this will trip up many others; to help, perhaps mentioning in the AppImage troubleshooting section?

@joedefen I read the article. Are you referring to my AppImage packages GIMP, VLC and similar... based on Arch Linux? Or is there something else I should know? Honestly, I didn't understand this point.

[Samueru-sama]

I also didn't understand that issue with apparmor well.

[ivan-hc]

From what I understand, some AppImages (maybe my "Archimages") use "BubbleWrap", which on Ubuntu conflicts with "AppArmor". "BWRAP" uses Linux NameSpaces to work. The article essentially says that using them is risky.

[Samueru-sama]

From what I understand, some AppImages (maybe my "Archimages") use "BubbleWrap", which on Ubuntu conflicts with "AppArmor". "BWRAP" uses Linux NameSpaces to work. The article essentially says that using them is risky.

iirc flatpak also uses bwrap.

And there is this tool which I wanted to contact the dev to add to am and remove firejail from am (firejail isn't considered a safe method for sandboxing anymore): https://github.com/mgord9518/aisap

[ivan-hc]

And there is this tool which I wanted to contact the dev to add to am and remove firejail from am (firejail isn't considered a safe method for sandboxing anymore): https://github.com/mgord9518/aisap

@Samueru-sama You reminded me that there was a time when I was looking for a sandboxing solution... I think it was a few years ago, before I wrote the --firejail option... and I came across this project too. Except that as a developer I was on my own.

[Samueru-sama]

And there is this tool which I wanted to contact the dev to add to am and remove firejail from am (firejail isn't considered a safe method for sandboxing anymore): https://github.com/mgord9518/aisap

@Samueru-sama You reminded me that there was a time when I was looking for a sandboxing solution... I think it was a few years ago, before I wrote the --firejail option... and I came across this project too. Except that as a developer I was on my own.

I just tested it this way with the librewolf appimage:

./aisap-0.9.8-alpha-x86_64.AppImage ./librewolf --trust-once

It works! but I need to read the documentation more to see how I can change the permissions for which directory to give access to.

It has a lot of potential to replace firejail!

[ivan-hc]

Aisap is also in the "AM" repository

[joedefen]

• BTW, when I run appman install --force-latest nvim with nvim uninstalled, it does nothing at all (i.e., no install of anything). I guess there is a fix for nvim in the works, and thus this may be moot.
• BTW, I published a "personal" visual wrapper atop appman with the most basic functionality (only appman, not am) ... see the description at: vappman. I know you have a GUI ticket open, but IMHO, this is 95% of the benefit (for me anyhow) with about 2% of the effort (hence it is quite usable with a few hours of effort).

Cheers.

[Samueru-sama]

• BTW, when I run appman install --force-latest nvim with nvim uninstalled, it does nothing at all (i.e., no install of anything). I guess there is a fix for nvim in the works, and thus this may be moot.

You shouldn't need to do that anymore as the nvim package was update to install the latest stable version.

And there is now nvim-nightly if you want the continuos build.

---

Thank you for making a GUI!

[Samueru-sama]

• BTW, when I run appman install --force-latest nvim with nvim uninstalled, it does nothing at all (i.e., no install of anything). I guess there is a fix for nvim in the works, and thus this may be moot.
• BTW, I published a "personal" visual wrapper atop appman with the most basic functionality (only appman, not am) ... see the description at: vappman. I know you have a GUI ticket open, but IMHO, this is 95% of the benefit (for me anyhow) with about 2% of the effort (hence it is quite usable with a few hours of effort).

Cheers.

Also btw, the issue hasn't been closed because we aren't sure of what the issue is with the original ubuntu website link you gave.

Like you want just a warning? Or is there a way to fix the issue that am can do?

[ivan-hc]

Honestly, from what I understand, @joedefen wants me to add an entry in "Troubleshot", on the READE.

I just don't know what I should write.

[ivan-hc]

BTW, when I run appman install --force-latest nvim with nvim uninstalled, it does nothing at all (i.e., no install of anything). I guess there is a fix for nvim in the works, and thus this may be moot.

fixed in the module install.am, run -s to update

[joedefen]

re: Like you want just a warning? Or is there a way to fix the issue that am can do?

I'm no expert on building/running appimages, but, largely I've never had any issues until now. My first reaction to the failures was to blame 'appman' and I gave up on it, and then went back only out of curiosity. Anyhow, all I would have needed to get things working quickly was a hint to the effect of:

• If you cannot run some AppImages on Ubuntu 23.10+ or its derivatives, then refer to Restricted unprivileged user namespaces are coming to Ubuntu 23.10 | Ubuntu for possible causes and remedies.

BTW, my little curses-based appman wrapper, vappman · PyPI is "complete" (to my liking anyhow); not sure if it has wider interest than my use.

[ivan-hc]

BTW, my little curses-based appman wrapper, vappman · PyPI is "complete" (to my liking anyhow); not sure if it has wider interest than my use.

Thanks, I think it is better to show and tell this at #8

Can you please also add a video or some screenshots of this?

I'm no expert on building/running appimages, but, largely I've never had any issues until now. My first reaction to the failures was to blame 'appman' and I gave up on it, and then went back only out of curiosity. Anyhow, all I would have needed to get things working quickly was a hint to the effect of:

If you cannot run some AppImages on Ubuntu 23.10+ or its derivatives, then refer to Restricted unprivileged user namespaces are coming to Ubuntu 23.10 | Ubuntu for possible causes and remedies.

So I'll add this at https://github.com/ivan-hc/AM?tab=readme-ov-file#cannot-mount-and-run-appimages

[ivan-hc]

@Samueru-sama @joedefen should I remove the spoilers and keep everything expanded?

[Samueru-sama]

@ivan-hc I think there also needs to be a check in AM that if x = restricted; then echo warning.

Also it would be great if AM could do the fixing, it think it is as simple as a single pkexec command, but I don't know what we exactly have to change in ubuntu to fix that issue.

EDIT: I think this is all that we have to do.

sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

[ivan-hc]

Also it would be great if AM could do the fixing, it think it is as simple as a single pkexec command

At most we can only give troubleshooting instructions.

but I don't know what we exactly have to change in ubuntu to fix that issue.

My experience on Ubuntu is equal to that of using the "wheel" group in Arch Linux. That is, zero.

EDIT: I think this is all that we have to do.

sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

It's not enough to just "think it's like this", the more detailed the instructions, the better.

Furthermore, @joedefen 's solution, that is, adding the URL to the README, is the most sensible one now.

As if on purpose, I set up the instructions by adding information about Electron-based apps:

---

Cannot mount and run AppImages

If by running it in the terminal you get an error message about "FUSE" or "libfuse"/"libfuse2" missing, take a look at the official documentation:

https://docs.appimage.org/user-guide/troubleshooting/fuse.html

If your distro does not provide libfuse2, you can install it using the command:

am -i libfuse2

or

appman -i libfuse2

NOTE, in AppMan you still need to use your password (sudo) to install the library at system level, in /usr/local/lib

Alternatively you can use the "nolibfuse" option to "try" to convert old Type2 AppImages to Type3, so as not to depend on libfuse2. In most cases it works, but sometimes it can give errors, depending on how the package was manufactured.

However, I suggest contacting the upstream developers to convince them to upgrade their packages to Type3.

• If you cannot run some AppImages on Ubuntu 23.10+ or its derivatives, then refer to Restricted unprivileged user namespaces are coming to Ubuntu 23.10 | Ubuntu for possible causes and remedies.
• If you cannot run chrome/chromium/electron-based AppImages, then refer to Troubleshooting/Electron-sandboxing for possible causes and remedies.

[Samueru-sama]

At most we can only give troubleshooting instructions.

Ok but if AM doesn't give the warning in the terminal, that is essentially nothing.

To this day I still see people that run into the issue of missing libfuse2 asking for help about that. This new issue is much less well known.

am -i libfuse2

You can also add export APPIMAGE_EXTRACT_AND_RUN=1 to your bash_profile / zprofile if you can't install libfuse2 in your distro. The only downside of this is that the appimages that get started don't get cleared out of tmpfs once they stopped being used, it basically means that there is an increased ram usage.

[ivan-hc]

I hated "--appimage-extract-and-run", I tried to do it with "0ad", 1.8 GB AppImage, which when extracted becomes 3... and it blocked my PC.

[Samueru-sama]

I hated "--appimage-extract-and-run", I tried to do it with "0ad", 1.8 GB AppImage, which when extracted becomes 3... and it blocked my PC.

That's no different than how the appimage regularly works though. The only diference is that those 3 GiB will still be on mem when you close the appimage that was launch with such env variable.

--appimage-extract-and-run needs to be added to each appimage, while export APPIMAGE_EXTRACT_AND_RUN=1 applies to all of them.