I recently updated my Ubuntu from 16.04 to 18.04, and one problem is the icon for the executable is the same as the one for a text file. (ArucoDetect is an executable, and others are usual text files)

ArucoDetect is an executable

In Ubuntu 16.04, the executable have it's own icon like


How can I configure Ubuntu 18.04 so the executable can have it's own special icon?

4 Answers 4


If you have problem than you can find gcc and add line -no-pie It is default executable because Ubuntu 18.04 has problem with Wayland that is why position independent executable. Just no pie! Than it works fine for me.

  • I tried compiled with -no-pie (only one dash in the front) and it solves it. Do you know whether there's any downside for compiling with this flag? Jan 31, 2019 at 22:24
  • Check makefile! You can find "gcc" with end of compilation like gcc main.c -o executable -no-pie than you see an executable and you can click executable. or ./executable in terminal. // UPDATED i.imgur.com/SFoD5uB.png Jan 31, 2019 at 23:07
  • You saved my life, thanks. Now, I'd like to have details regarding why this works, and why the hell the file browser in Ubuntu 18 thinks executable aren't executable when not compiled with "-no-pie".
    – dim
    Nov 8, 2019 at 13:38
  • check your file with "file --mime-type ArucoDetect". Could be that you created a mimetype Ubuntu doesn't know about...
    – kanehekili
    Nov 8, 2019 at 19:46
  • Welcome for saving your life! I worked with mkbundle.cs with -no-pie Jun 26, 2020 at 17:22

This answer exists solely of a continuation of Piggybacking off of Jens' answer of using -no-pie as part of GCC builds...

This is a bug caused by Position Independent Executables (PIE). PIE is a security feature in modern versions of Linux that randomizes memory addresses as well as slightly changes file structures. PIE binaries are different from "standard" Linux binaries because PIE binaries have a different type - most systems (notably, file) will treat them as a Shared Library file instead of a plain-old executable binary:

$ file bin-nopie
bin-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=ee817f6d5d4f5635a981b1b837b1b0de3b16aacf, not stripped

$ file bin-pie
bin-pie:   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=439fc92838d4d0981f99dd967485e5b95a5a0e7b, not stripped

Ubuntu's file browser (Nautilus) doesn't do its own filetype processing (it instead elects to use libmagic/file/etc.). As these upstream libraries are broken and are unable to detect PIE-built binaries properly, Nautilus is not able to show them as executable in the GUI. The system, therefore, elects to treat them as though they are any other shared library (that is, as a non-executable).

However, this problem can be mitigated away. A developer can compile a binary using the -no-pie option to disable PIE (although this does harm security a little bit). This will allow libmagic/file to see the binary file as an executable binary and pass that data on accordingly to Nautilus. Alternatively, a developer (or an end-user) may create a .desktop file pointing to the binary. This is considered the "preferred" workaround by the GNOME team, as it allows addition of metadata and icon files, creating an overall prettier user experience.

Open/Related Bug Reports:


This has to do with mime types and has nothing to do with whether a file is executable or not. All the scripts I use are of course executable but that doesn't change the fact that the Mime type is different.

Examples: Busybox has the icon executable icon that is shown in the question.

$ file /bin/busybox

/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=86b86ebdeb1e423dc1672c2a7408fb83ee70eeb1, stripped

My scripts on the other hand have icons similar to: text style icons

file ~/bin/vdprocessx265.sh

/home/me/bin/vdprocessx265.sh: Bourne-Again shell script, ASCII text executable, with very long lines

As you can see, the bash script while executable is a shell script in ASCII text while busybox is an ELF executable.

using grep on /etc/mime.types makes it even more clear.

grep "exe" /etc/mime.types


application/x-msdos-program com exe bat dll

grep "sh" /etc/mime.types

Users can add their own types if they wish by creating a ".mime.types"


text/x-csh csh

text/x-sh sh

There are a couple good answers to How do I change the icon for a particular file type? that should help you get the results that you want.

This question has answers that go into further detail: Where are file associations stored?

@dim I believe that you'll find that compiling with the -no-pie switch results in a different header

mimetype guesses the appropriate mime type based on the contents of the file. For ELF files (most compiled binaries and shared libraries), the header contains a field e_type which identifies its type. If it is ET_DYN, then mimetype will treat it as a shared library.

By default, gcc/ld will produce binaries which set e_type to ET_EXEC, which get detected as application/x-executable

which causes the mimetype to be guessed diferently as explained by this StackOverflow answer hence the different icon.


Where are file associations stored?

How do I change the icon for a particular file type?




Change your application's name to ArucoDetect.appimage

  • It does changes the icon by adding .appimage but shouldn't it work without having to add that extension? Jun 7, 2018 at 18:37
  • Is this the same Problem? stackoverflow.com/questions/50412577/…
    – Tim
    Jun 7, 2018 at 19:18
  • No this file is an executable. Even if I do chmod a+x again on the file the icon still doesn't change. Jun 7, 2018 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.