37

Simple question, how can I extract files from an AppImage?

GUI, CLI, it doesn't matter, as long as it gets the job done.

I'm using openSUSE Tumbleweed if it matters

3

7 Answers 7

41

First, look if your AppImage file is using the newest version of its internal format:

/path/to/your.AppImage --appimage-help

If you see the following line in the output:

--appimage-extract              Extract content from embedded filesystem image

you can conclude yourself how to proceed. In this case you have a (newer) type 2 AppImage format in front of you. (The 'path' part of the command may be relative or absolute.)

Second, if the first command didn't work, you can use a helper tool. However, you need sudo/root privileges for this: download appimagetool (which off course is available as an AppImage). Make it executable and run:

/path/to/appimagetool-x86_64.AppImage --list /path/to/your.AppImage

This should give you a list of all files and their (relative) paths embedded in your.AppImage. To extract your.AppImage into a directory named and located at /path/to/somedir , run

mkdir /path/to/somedir
/path/to/appimagetool-x86_64.AppImage /path/to/your.AppImage /path/to/somedir

Third, you can mount AppImages (type 1 as well as type 2) without the helper tool too:

  • Type 1:

    mkdir mountpoint
    sudo mount -o loop my.AppImage mountpoint/
    
    # You can now inspect the contents
    # You can now also copy the contents to a writable location of your hard disk
    
    sudo umount mountpoint/
    # Do not forget the umount step!
    # If you do forget it, your system may exhibit unwanted behavior.
    
  • Type 2:

    mkdir mountpoint
    my.AppImage --appimage-offset
    123456   # This is just an example output
    
    sudo mount my.AppImage mountpoint/ -o offset=123456
    
    # you can now inspect the contents
    
    sudo umount mountpoint/
    # Do not forget the umount step!
    # If you do forget it, your system may exhibit unwanted behavior.
    

Hint for the 'paranoid': If you do not want to trust the AppImage, the third method is preferable. Because running (for type 2 AppImages) the.AppImage --appimage-extract or the.AppImage --appimage-mount or the.AppImage --appimage-offset means you are actually executing an AppImage (though not its content).

Update:

To answer the question of @jayarjo in the comment below (how to re-package the AppImage after modifications?):

  1. You can use appimagetool not just to extract an existing AppImage into an AppDir. You can use it to also re-package the AppDir (possibly after some changes) back into a (modified) AppImage.

  2. Just run

     appimagetool -v /path/to/AppDir
    

    Watch output of command (made verbose by -v) for the location and name of the newly created AppImage. That's it.

3
  • Do you know how to pack it back? Suppose I've extracted it, altered some scripts and now want to create an AppImage out of it.
    – jayarjo
    May 19, 2019 at 6:56
  • 1
    @jayarjo: You can use appimagetool not just to extract an existing AppImage into an AppDir. You can use it to also re-package the AppDir (possibly after some changes) back into a (modified) AppImage: "appimagetool -v /path/to/AppDir". Watch output of command (made verbose by -v) for location of newly created AppImage. That's it. May 19, 2019 at 11:10
  • The second method (Using AppImage tool) only works for Type 1 AppImages currently. appimagetool errors out with a "To be implemented" error message in such cases.
    – Nemo
    Apr 30, 2022 at 4:40
4

rename extension to .7z

$ mv file.AppImage file.7z

extract with file-roller

$ file-roller --extract-here file.7z 

Tested on Linux Mint.

1
  • Your answer (extract command) throws an error: GtkDialog mapped without a transient parent. This is discouraged, and commands exits (CentOS).
    – pebox11
    Mar 9, 2023 at 20:57
2

I only rename with right clic, example:

compress-pdf-v0.1-x86_64.AppImage

to:

compress-pdf-v0.1-x86_64.zip

then right clic

"Extract Here"

and working

extract all files inside in one folder

1

The --appimage-extract might not work sometimes:

./your.AppImage --appimage-extract

However, mount does

mkdir /tmp/mountpoint
sudo mount -o loop your.AppImage /tmp/mountpoint
1

Based on the answer here, I've create this simple bash script. But I've never encounter an AppImage that I could extract with a loop device. EDIT: Just did: "wxHexEditor"

Here:

#!/bin/bash

APP="$2"
UNPK="$(echo $APP | sed 's/\.AppImage//')"

case "$1" in
  -a)
      chmod +x $APP;
      ./$APP --appimage-extract
      mv squashfs-root $UNPK
      ;;
  -b)
      mkdir -p /tmp/$UNPK
      sudo mount -o loop $APP /tmp/$UNPK &>/dev/null
      mkdir -p ~/Desktop/$UNPK
      cp -R /tmp/$UNPK/* ~/Desktop/$UNPK &>/dev/null
      sudo umount /tmp/$UNPK
      ;;
  *)
      echo
      echo "   Usage: appunpack [option] AppImageFile"
      echo 
      echo "   Options: -a  Unpack using --appimage-extract"
      echo "            -b  Unpack using a loop device"
      ;;
esac
1

I faced to the same problem when I needed to extract appimagetool in aarch64 chroot environment. The problem was the AppImage application was not possible to execute because of: Exec format error

The all problem is howto get offset of squashfs file system. If you have it, you can use one of the method already described here. Finally the solution is pretty simple. I guess I am working with Type 2 AppImage. At the start of the AppImage is ELF file and than image of squashfs. The size of ELF file (= offset of AppImage) can be computed based on the information of readelf -h AppImageFile. See here Size of ELF file

For my needs I wrote simple bash script. Expect the image is stored at /tmp/appimagetool

    ELFSIZE=$(readelf -h /tmp/appimagetool)
    START_OF_SECTION=$(echo $ELFSIZE | grep -oP "(?<=Start of section headers: )[0-9]+")
    SECTION_SIZE=$(echo $ELFSIZE | grep -oP "(?<=Size of section headers: )[0-9]+")
    SECTION_NO=$(echo $ELFSIZE | grep -oP "(?<=Number of section headers: )[0-9]+")
    APPIMG_OFFSET=$(( $START_OF_SECTION + $SECTION_SIZE * $SECTION_NO ))

Extract image to folder /usr/local/share/appimagetool by command

unsquashfs -o $APPIMG_OFFSET -d /usr/local/share/appimagetool /tmp/appimagetool

Finally can create link to the executable:

ln -s /usr/local/share/appimagetool/AppRun /usr/local/bin/appimagetool
0

As also answered here, you can use binwalk to disassemble the appimage,
locate the squashfs image,
and unsquash it.

Here's what worked for me

cat <<EOF > ~/SCRIPTS/archive.appimage.extract
#!/bin/bash
appimage="$1"
temp=$(mktemp -d)
cd "$temp"
binwalk -e "$1"
find . -name "*.squashfs" -exec unsquashfs -li {} \;
echo "extracted $appimage files to $temp"
EOF
$ chmod +x ~/SCRIPTS/archive.appimage.extract
$ ~/SCRIPTS/archive.appimage.extract /path/to/appimage

Files will be extracted somewhere to /tmp/,
as printed by the script.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .