Issues with fuse when using AppImage tool in Docker container

[philippgille]

This might not be an issue with AppImage tool itself, but others might have trouble building an AppImage with Docker containers as well, so I thought I'd create an issue here. Mabe resolve this issue by extending documentation.

I'm trying to package a self-contained .Net Core console application as AppImage. On a Ubuntu 16.04 VM this works fine. But in a Docker container it doesn't.

The Docker container is microsoft/dotnet:1.1-sdk, which inherits from buildpack-deps:jessie-scm, which inherits from buildpack-deps:jessie-curl, which inherits from debian:jessie. The host is the aforementioned Ubuntu 16.04 VM.

I run AppImage tool from within a build script. The steps are:

# ...snip
# Copy SCD files
cp -r $ARTIFACTSDIR/${APPNAME}_ubuntu.16.04-x64 $SCRIPTDIR/../appimage/AppDir/usr/bin/
# Make sure AppRun is executable
chmod u+x $SCRIPTDIR/../appimage/AppDir/AppRun
# Download AppImage creation tool and make it executable
curl -Lo /tmp/appimagetool-x86_64.AppImage https://github.com/probonopd/AppImageKit/releases/download/8/appimagetool-x86_64.AppImage
chmod u+x /tmp/appimagetool-x86_64.AppImage
# Create AppImage
/tmp/appimagetool-x86_64.AppImage -u $SCRIPTDIR/../appimage/AppDir/ $ARTIFACTSDIR/${APPNAME}_ubuntu.16.04-x64.AppImage

This leads to the following output:

# ...snip
+ /tmp/appimagetool-x86_64.AppImage /root/scripts/../appimage/AppDir/ /root/scripts/../artifacts/hello-netcoreapp_ubuntu.16.04-x64.AppImage
/tmp/appimagetool-x86_64.AppImage: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory

After apt update && apt install -y libfuse-dev and running the build script again (all within the container):

# ...snip
+ /tmp/appimagetool-x86_64.AppImage /root/scripts/../appimage/AppDir/ /root/scripts/../artifacts/hello-netcoreapp_ubuntu.16.04-x64.AppImage
fuse: device not found, try 'modprobe fuse' first

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/probonopd/AppImageKit/wiki/FUSE
for more information
open dir error: No such file or directory

For further info, within the container:

apt install kmod && modprobe fuse
modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.57-std-1/modules.dep.bin'

I found this on StackOverflow: https://askubuntu.com/questions/459296/could-not-open-moddep-file-lib-modules-3-xx-generic-modules-dep-bin-when-mo

So with the changed package name I tried apt install --reinstall linux-image-3.16.0-4-amd64, but it didn't help (and probably is bogus to do in a container anyway?).

I also tried restarting the container after libfuse-dev installation, without the previous command, so within the newly created dotnet:1.1 container it was just apt update && apt install -y libfuse-dev && exit and then start the container again and run the build script. But it didn't help as well.

I then searched if I was doing anything wrong regarding the fuse installation and found this: https://stackoverflow.com/questions/24966347/is-s3fs-not-able-to-mount-inside-docker-container

Maybe some of those other packages needed to be installed. fuse-utils doesn't exist in the package repositories, but when searching with apt search fuse I found the fuse package and tried to install it. This lead to:

/var/lib/dpkg/info/fuse.postinst: 18: /var/lib/dpkg/info/fuse.postinst: lsmod: not found
MAKEDEV not installed, skipping device node creation.

And the build script didn't work yet, so within the container: apt purge fuse && apt install -y kmod makedev fuse

mv: cannot move 'console-' to 'console': Device or resource busy
makedev console c 5 1 root tty 0600: failed

There weren't many useful search results for that, except maybe https://bugs.launchpad.net/ubuntu/+source/makedev/+bug/927519, but that's specifically regarding a makedev upgrade, and also the bug was marked as fixed by the makedev developers.

Now I don't know what else to try.

Sooooo: Does anyone have any ideas or suggestions what to try next? Or maybe someone solved that issue already?

[probonopd]

Basically you have two options here:

1. Fix your Docker setup so that FUSE works (it's doable but @TheAssassin will likely chime in to explain why this may be a bad idea tough)
2. Extract the AppImage and run the commands from the extracted AppImage

To do 2., you could do instead of

/tmp/appimagetool-x86_64.AppImage /root/scripts/../appimage/AppDir/ /root/scripts/../artifacts/hello-netcoreapp_ubuntu.16.04-x64.AppImage

do this:

/tmp/appimagetool-x86_64.AppImage --appimage-extract
./squashfs-root/AppRun /root/scripts/../appimage/AppDir/ /root/scripts/../artifacts/hello-netcoreapp_ubuntu.16.04-x64.AppImage

In fact, that is exactly what

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/probonopd/AppImageKit/wiki/FUSE
for more information

is meant to say. If you have ideas on how to make that message more understandable, I'd be glad to hear from you.

[TheAssassin]

Yep, I already had to tell many people not to activate FUSE in Docker. It doesn't work for security reasons, and everything that magically makes it work effectively bypasses those restrictions. That is generally not desirable, and by extracting the AppImage, it isn't even necessary.

See e.g. nextcloud/client_theming#162 (comment).

Check out redeclipse-appimage's build script for an example that works both in and outside Docker.

[probonopd]

@philippgille please let's know whether this answers your question, thanks.

[philippgille]

Oh okay, I thought the issue was in creating the AppImage for my app, but it's running the AppImage tool AppImage that's already causing the error.

And shame on me for not reading https://github.com/AppImage/AppImageKit/wiki/FUSE.

So I wanted to go with option 2.

I wanted to try this on an actual host first instead of in a Docker container, and I used a fresh VM instead of the previously used one (to make sure my build script runs everywhere).

/tmp/appimagetool-x86_64.AppImage --appimage-extract
/tmp/appimagetool-x86_64.AppImage: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory

Okay, maybe the mounting option works that's mentioned on the FUSE wiki page

mount -o loop /tmp/appimagetool-x86_64.AppImage /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

No luck :(

Further info:

• The used appimagetool-x86_64.AppImage is from release 8, because I can't afford any breaking changes that might get introduced in the continuous release.
• Fresh VM is Ubuntu 16.04 x64

[TheAssassin]

The mount version cannot work inside Docker either, same restrictions as above.

I cannot reproduce your issue about FUSE not found for --appimage-extract. This can effectively not happen with up to date appimagetool copies, as FUSE is loaded only when necessary via dlopen(). The only case in which you might meet this linker error is when you have an old copy. Please run --appimage-version or fetch a new copy from https://github.com/AppImage/AppImageKit/releases.

I am updating the Wiki about FUSE right now by the way. You'll find "option 2" documented there soon.

[TheAssassin]

JFYI: article has been updated.

[philippgille]

Thank you so far for the great help here!

As mentioned in the previous comment, I used the appimagetool-x86_64.AppImage from release 8, so Feb 19. I just saw you released a new version 2 days ago, which I will test in a second.

[TheAssassin]

@philippgille yeah that's most likely the problem. I must've missed you mention that. I use the bleeding edge "continuous release" most of the time.

[philippgille]

I didn't have it in my initial comment, I edited it shortly afterwards, but before you wrote your answer. Maybe you read my comment via email?

Anyway, I wasn't able to test it yet, because yesterday I installed fuse in the VM to finally get a working AppImage build of my app. But now even after apt purge fuse and rebooting the VM, the appimagetool AppImage still works without extracting, although it shouldn't (without fuse). I don't know why. I'll create a fresh VM without fuse installed in the next days and try again with release 8, which should fail, and then with extract, which should fail as well, and then with release 9, which should still fail, and then with extract of release 9, which should work.

[philippgille]

Found time for some testing today.

All in a new Ubuntu 16.04 VM:

FUSE installed	appimagetool version	appimagetool extract	result
X	8	X	X
X	8	V	X
X	9	X	X
X	9	V	V

Success!

So, thank you very much for pointing me to the --appimage-extract option and for creating release version 9, without which I couldn't use the option.

Some people can't afford using continuous releases, as they might introduce changes that are incompatible to the way the software was used before (e.g. you switch from Bintray to another service and the related flags stop working), or might result in an AppImage that behaves differently, or ...
So: Keep the tagged releases coming :)

I edited the FUSE wiki page to mention the needed appimagetool version, see the change here

Closing the issue.

[philippgille]

Sorry, I was a bit too quick.

The above table shows the results from the Ubuntu VM directly, not from a Docker container. Now I tried my build script in a Docker container and I'm getting this error:

./squashfs-root/AppRun /root/scripts/../appimage/AppDir/ /root/scripts/../artifacts/hello-netcoreapp_ubuntu.16.04-x64.AppImage appimagetool: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory

[probonopd]

libglib-2.0.so.0 is one of the basic libraries that are assumed to be part of the base system (provided by each distribution). Please install it from your package manager.