appimagetool: ".DirIcon is an SVG image … must be a PNG" or "has mode 0700": one fix that works on the old and the new build

Is this you?

You run the continuous appimagetool (many CI scripts download https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage), and it exits with status 1 and creates no AppImage. Its first lines name the build:

appimagetool, continuous build (git version 9bab981), build 340 built on 2026-10-31 09:33:46 UTC

Then one of these errors. foo is your Icon= name; the paths are your own.

No PNG icon at the top level of the AppDir:

Problem: .DirIcon does not exist, and no foo.png or foo.xpm was found in the top level of the AppDir (Icon=foo in the .desktop file) to create it from

.DirIcon points to an SVG. appimagetool 1.9.1 and linuxdeploy both create this link when the icon is an SVG:

Problem: .DirIcon is an SVG image (/path/to/AppDir/foo.svg). SVG is hard to parse, so file managers and thumbnailers cannot be expected to handle it; .DirIcon must be a PNG

Both icon errors end with:

appimagetool: no AppImage was created because .DirIcon is not valid.

The AppDir itself has mode 0700. mktemp -d creates directories with this mode:

Problem: this directory has mode 0700 (rwx------), so some users (group and/or others) cannot read and execute it. AppImages are run by users other than the one who packaged them, who would get 'Permission denied'. It needs at least mode 0755 (rwxr-xr-x)

AppRun has mode 0700:

Problem: this program/script has mode 0700 (rwx------), so some users (group and/or others) cannot read and execute it. AppImages are run by users other than the one who packaged them, who would get 'Permission denied'. It needs at least mode 0755 (rwxr-xr-x)

If the AppDir was written under a strict umask such as 077, top-level files like the .desktop file and the icon fail the same way:

Problem: this file has mode 0600 (rw-------), so some users (group and/or others) cannot read it. AppImages are run by users other than the one who packaged them, who would get 'Permission denied'. It needs at least mode 0644 (rw-r--r--)

The permission errors end with this line; the number is how many paths failed:

appimagetool: found 1 ERROR(S) in the AppDir, nothing was changed and no AppImage was created.

In our runs, appimagetool 1.9.1 packaged each of these four AppDirs and exited with status 0.

Not this change: if your only icon is under usr/share/icons/… and there is none at the top level, 1.9.1 refuses it too (foo{.png,.svg,.xpm} defined in desktop file but not found). Both builds' messages say to put a PNG at the top level, as in step 1 below.

The fix

1. Put a PNG icon at the top level of the AppDir, named after the Icon= value in your .desktop file. If you only have an SVG, convert it with rsvg-convert. It is in the librsvg2-bin package on Ubuntu and Debian. The software list of GitHub's ubuntu-24.04 runner image does not include it, so install it in the job:

sudo apt-get update
sudo apt-get install -y librsvg2-bin
rsvg-convert -w 256 -h 256 AppDir/foo.svg -o AppDir/foo.png

GitHub has announced that ubuntu-latest moves to Ubuntu 26.04 in November 2026. The rsvg-convert fix passed in our Ubuntu 26.04 container too.

If your SVG is somewhere else, give its path as the input; the output must be AppDir/foo.png. The new build's own error message suggests 256 by 256 pixels. If your SVG is not square, -w 256 -h 256 stretches it; add -a to keep its proportions (the PNG is then smaller on one side; the new build packaged it in our check). In a container job that runs as root without sudo, leave out sudo.

Check the PNG if you use ImageMagick instead. With a normal apt-get install imagemagick, which also installs its recommended packages, convert -background none -resize 256x256 foo.svg foo.png turned the gradient in an icon solid black on Ubuntu 24.04 and 26.04. On 26.04, convert exited with status 0 and both appimagetool builds packaged the black icon with no AppDir warning. Neither build looks at the picture: the new build only checks that the file starts like a PNG, and 1.9.1 does not check the file type at all. rsvg-convert drew the same icon correctly.

2. Delete the old .DirIcon:

rm -f AppDir/.DirIcon

Both builds create .DirIcon from the Icon= PNG when it is missing. If your old .DirIcon is a link to the SVG, this step is optional: with foo.png at the top level, the new build replaced that link by itself and packaged the AppDir. If it is a regular file, for example a copy of the SVG, the new build keeps it and fails; the error then names .DirIcon itself in the brackets, as in (/path/to/AppDir/.DirIcon). The rm covers both.

3. Make the AppDir readable for everyone. Run this last, after the PNG exists: under a strict umask, rsvg-convert writes the PNG with mode 0600.

chmod -R a+rX AppDir

This fixed both the 0700 AppDir and the 0700 AppRun: both became 0755. It adds execute permission only to directories and to files that someone can already execute. If AppRun is not executable at all, also run chmod a+x AppDir/AppRun. Write a+x, not +x: under a umask of 027 or 077, chmod +x left AppRun at 0754 or 0744, and the new build refused it.

After these steps, the new build and 1.9.1 each packaged every AppDir we fixed this way, with exit status 0 and no AppDir warnings.

Why --no-check-permissions is not enough

--no-check-permissions turns off the permission errors only. With it, the 0700 AppDir and the 0700 AppRun packaged. The SVG icon cases still failed with exit status 1 and no AppImage. There is no flag that accepts an SVG .DirIcon.

Or pin 1.9.1 for now

https://github.com/AppImage/appimagetool/releases/download/1.9.1/appimagetool-x86_64.AppImage has none of these checks, and packaged all four cases in our runs. The AppImage it builds still has the problems the new build reports. One appimagetool maintainer answered a user who pinned 1.9.1: "Then you continue to produce broken AppImages."

The warnings banner

Other permission problems, such as a 0700 usr/ directory or a 0600 library, are warnings. appimagetool creates the AppImage, exits with status 0 and prints a banner at the end:

################################################################################
#  appimagetool: 2 WARNINGS ABOUT YOUR APPDIR - PLEASE FIX THEM
################################################################################
If these are not fixed, this AppImage would very likely FAIL the automated tests
at https://appimage.github.io, and may crash with 'Permission
denied' or similar errors for users other than you.
appimagetool exits with code 0 because of warnings only. THIS MAY CHANGE IN A
FUTURE VERSION, when these warnings may become errors that stop the build.

With GITHUB_ACTIONS=true, as in a GitHub Actions job, appimagetool also prints each warning as a ::warning line, which shows as an annotation on the run. The banner itself says to run chmod -R a+rX on the AppDir to fix all read and execute warnings at once; we did not rerun this case with it.

If you use linuxdeploy

linuxdeploy --output appimage with an SVG icon (-i foo.svg) still works today. linuxdeploy packages with an appimagetool built into its AppImage plugin, from December 2025, which does not have these checks. An appimagetool on your PATH does not change that: we put the new build there, and linuxdeploy still used its own.

After --output appimage, the AppDir linuxdeploy built has .DirIcon pointing to the SVG. When we ran the new appimagetool on it directly, it failed with the .DirIcon is an SVG image error. Passing a PNG as well (-i foo.png -i foo.svg) did not help: linuxdeploy still pointed .DirIcon at the SVG and put no PNG at the top level. If you run only linuxdeploy --appdir … and package it yourself, there is no .DirIcon at all, and the new build shows the first error above (.DirIcon does not exist …); the fix on this page passed in that order too.

So linuxdeploy users with an SVG icon are unaffected today. When linuxdeploy is next rebuilt with a refreshed AppImage plugin that carries a current appimagetool, we expect the same error unless the AppDir has a PNG icon at the top level. We did not run a rebuilt plugin; this follows from the direct run above. A change to make linuxdeploy prefer a PNG for the top-level icon is open as linuxdeploy#341. We do not know when either project will rebuild.

Where this stands

• 29 October 2026, 19:14 UTC: appimagetool#135 added these checks and made every permission problem stop the build.
• 30 October: users reported broken workflows in appimagetool#138.
• 31 October, 09:32 UTC: appimagetool#139 kept as errors only the modes of the AppDir itself, AppRun, the .desktop file, the top-level icon and the .DirIcon target, and a .DirIcon that is missing, broken, not a regular file or an SVG. Everything else became a warning. (#139's description also lists AppRun.wrapped as an error; this build only warns about it.) The continuous build this page describes was published a few minutes later.
• 31 October, 21:47 UTC: a linuxdeploy maintainer proposed turning all the checks back into warnings for now. The same appimagetool maintainer quoted above replied: "I have already relaxed some of the tests based on the feedback received."

As of 1 November 2026, 01:00 UTC, the continuous build is still the one from 31 October 09:35 UTC. If the checks are turned back into warnings, the fix above still works: it gives an AppDir with nothing to warn about.

Builds without network access

appimagetool downloads its runtime while it packages. In a build with no network access it fails with Failed to download runtime: server returned status code 0. Download runtime-x86_64 from AppImage/type2-runtime beforehand and pass it with --runtime-file. That is how we ran every appimagetool test on this page.

What we tested

• appimagetool continuous as published 31 October 2026 09:35 UTC (git version 9bab981, build 340, sha256 ac7fd56f…0666cab) and appimagetool 1.9.1 (git version 8c8c91f, sha256 ed4ce84f…384eb0). linuxdeploy continuous (git 07333c6, build 369) with its built-in AppImage plugin.
• Each AppDir was packaged in ubuntu:24.04 and ubuntu:26.04 containers with no network, as a normal user, with APPIMAGE_EXTRACT_AND_RUN=1, --runtime-file and --no-appstream. Both images gave the same appimagetool result in every case with the same input. rsvg-convert was librsvg 2.58.0 on 24.04 and 2.61.3 on 26.04. The converters were installed in the test images beforehand, so the apt-get lines were not part of the runs.
• Cases: a clean AppDir with a top-level PNG; SVG only; SVG with .DirIcon pointing to it; AppDir mode 0700; AppRun mode 0700; usr/ 0700 with a 0600 library; icon only under usr/share/icons/; a top-level PNG with an old .DirIcon pointing to an SVG; and one AppDir with all of SVG .DirIcon, 0700 AppDir and 0700 AppRun. Each ran on both builds, and on the new build with and without --no-check-permissions.
• A .DirIcon that is a regular-file copy of the SVG was checked once, separately and outside the containers above, on the same new build: with a top-level PNG and after chmod -R a+rX, it still failed with the SVG error. The rm step was tested on AppDirs whose .DirIcon was a link; after the rm, both kinds of AppDir are the same.
• A second check used a real-app layout: a reverse-DNS Icon= name, a non-square SVG drawn with a gradient, AppRun as a link into usr/bin/, and an AppDir from mktemp -d under umask 077. It also covered an AppDir built with linuxdeploy --appdir, an AppRun without execute permission, and ImageMagick with and without its recommended packages. The page's steps passed on both builds; the ImageMagick and chmod +x results are the ones described above.
• Not tested: GitHub's own runner images (the containers stand in for them), arm64 and other architectures, AppStream checks, a rebuilt linuxdeploy plugin, and other converters such as Inkscape.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something on this page is wrong or has changed, email hello@cybernative.ai. We correct the page and list each correction here with its date.