I have a desktop application that provides the user with a tarball (.tar.gz) that they can unpack to find the binary that can be run with executable permissions which starts the overall program. This works on the user's main disk but if it is on a removable media such as a USB or external HD it does not (with Windows this works). Each time I try to change the permissions, starts with 'r' and 'w', using chmod the permissions revert to exclude executable permissions even as root.

Current mount info for the mount point /dev/sda1 on /media/me/78E1-495A type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

There are other posts about this issue: related ask ubuntu question which has some interesting solutions such as mounting with a permission alteration, but does that not require re-mounting to another location (answer incomplete)? Here in this question an answer provides a solution answer with mount -o -exec, that uses a new mount point with the exec option but this is not changing the default non-execute options.

Is there a solution to this that does not involve altering any of the configuration files of the user's system?

  • Is there a solution to this that does not involve altering any of the configuration files of the user's system? None that I'm aware of. You could instead unpack the tar.gz to any native Linux directory and you're good to go. Jul 31, 2022 at 19:15
  • 1
    This link might help you solve the problem by unmounting and mounting with 'execute' in the mount options. Scroll down to 'Example 2 (with execute permissions for files ...)'
    – sudodus
    Aug 1, 2022 at 7:37
  • If there is no specific configuration to say otherwise, udisk2-based desktop mount helpers for removable media are likely to default to disabling the execute permissions, as indiscriminately executing software of uncertain origin is one of the well-known easy ways to get malware on your system.
    – telcoM
    Aug 5, 2022 at 12:30

2 Answers 2


The vfat filesystem type (which is typical for a USB stick) does not support storing the permissions chmod is trying to modify. vfat is a windows derived filesystem, so it isn't too surprising it doesn't support unix file semantics completely.

Additionally, the showexec option blocks the execute bit. According to the man page for mount,

If set, the execute permission bits of the file will be allowed only if the extension part of the name is .EXE, .COM, or .BAT. Not set by default.

Without the showexec mount option, probably all files would be marked as executable, and the chmod -x command would still do nothing.

  • does this mean there is a solution using the showexec ?
    – Vass
    Jul 31, 2022 at 21:37
  • err...not exactly. Possibly not using showexec.
    – user10489
    Jul 31, 2022 at 22:36

The file system UDF

You can use the file system UDF where you can manage ownership and permissions rather freely so that a directory can be writable and programs can be executable.

  • UDF probably lacks tools to repair the file system, which is a disadvantage, but there are several advantages.

  • FOSS

  • Maybe it is possible to find repair tools in Windows via this link: fsck tools for UDF, and there is some tool available as source code

  • Can be created in Ubuntu

  • Compatible with linux style links.

  • Compatible with linux style permissions and ownership. You can create and modify ownership and permissions of individual files (which is not possible with FAT and NTFS).

  • A UDF partition will not be prompted for formatting by Windows 10 (while the linux ext4 file system is affected, and can be destroyed by mistake).

  • How to create and use UDF: Using the UDF as a successor of FAT for USB sticks

    So, to use it, assuming your USB stick is /dev/sdx:

    1. Install the package udftools (in Ubuntu and Debian)

            sudo apt-get install udftools
    2. Create a partition table and one partition with gparted or gnome-disks

    3. Wipe the first mibibyte of the target partition with the risky dd (double-check the command line!)

            sudo dd if=/dev/zero of=/dev/sdx1 bs=1M count=1
    4. Run mkudffs,

            sudo mkudffs -b 512 --media-type=hd --lvid=my-label /dev/sdx1

    Wipe the first mibibyte of the partition to erase the previous file system information (or other remaining data), to prevent you USB stick from being detected as a FAT after it has been formatted with UDF.

    The -b 512 is to force a file system block size equal to the USB stick's physical block size, as required by the UDF specification. Adapt it if you have the luck of having a USB stick with a more appropriate block size.

    After that, your USB stick will be usable for reading and writing with GNU/Linux but also with current versions of Windows (read-only with the outdated version XP). Unfortunately this version of UDF created in Linux cannot be managed by MacOS (tested in several versions of MacOS in November 2020).

Test example

I made the following system in a USB stick,

$ lsblk -o name,size,fstype,label,mountpoint /dev/sdc
sdc    57,3G                  
└─sdc1  3,5G udf    work-here /media/olle/work-here

The partition with UDF automounts in my computers.

I made a directory (with sudo) at the top level in the UDF file system and modified its ownership and permissions in order for the first regular user to get ownership and full permissions.

sudodus@bionic64 /media/sudodus/work-here/cd-2-this-dir $ ls -l /media/sudodus/work-here
totalt 0
drwxr-xr-x 2 sudodus sudodus 196 aug  2 23:14 cd-2-this-dir

Then I created a small bash shellscript and gave it execute permissions

chmod +x run-this-file
sudodus@bionic64 /media/sudodus/work-here/cd-2-this-dir $ ls -l
totalt 0
-rwxrwxr-x 1 sudodus sudodus 49 aug  2 23:14 run-this-file

and it can be executed in this location (in the USB drive),

sudodus@bionic64 /media/sudodus/work-here/cd-2-this-dir $ ./run-this-file 
Hello World, I am sudodus

After this exercise in my main computer (in Ubuntu 18.04.6 LTS) I tested in Ubuntu 22.04 LTS and in Windows 11. I made a bat file and it was executable by


Final comments

I think this method with UDF works to make your program package available in Linux and Windows.

Unfortunately I have no smooth method that works also with MacOS. If you need a method that works with MacOS, I think the user needs FAT32 or exFAT and must unmount and mount again, this time with the mount option exec added according to this link. Scroll down to 'Example 2 (with execute permissions for files ...)'.

What can be done [to make it more user friendly] is to have a small shellscript that can run those commands from a small partition and modify the mount options of a bigger partition on the same drive,

sudo bash make-execution-possible

This works without executable permissions (but only for shellscripts, and I think you have some compiled programs).

You must log in to answer this question.

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