Whenever I download an exe file to that partition in Windows, I cannot run it at all. It gives me the error: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."


I have a dual boot setup with Arch Linux and Windows 10. I have a 1TB HDD with NTFS Usermap set up in Arch Linux for an NTFS partition on that HDD as follows:

# Generated by ntfsusermap for Linux, v 1.2.0

I can successfully mount and use that NTFS partition as any other partition (with chmod and chown working fine).

The fstab entry for that partition is as follows:

# /dev/sda1 LABEL=Data
UUID=0492DE6F92DE64A8   /mnt/Data   ntfs        rw,nosuid,nodev,relatime,uid=1000,gid=1000,allow_other,dmask=022,fmask=133  0 0

I can read and write to files created on Arch in Windows normally. I can also create non-executable files on Windows and use them on Arch Linux normally.


Running a new exe file normally fails, even when running it as an administrator. The only way to get it to work is to allow everyone to have full control of that file in Windows through the security tab in the file permissions.

It seems like new files can be read and written to, but they cannot be executed on that partition. This is not the case for other partitions (the one on my SSD).

When I inspect the permissions of a newly downloaded exe file in Linux, it seems to be missing the executable permission. Using chmod to set the executable bit for all (in Linux) does not help in getting it to run that file in Windows. When I use Windows Powershell and run the Get-Acl command on a new exe file (which doesn't run) and an older one created before the Usermap (which runs fine), I get the same output, ie. the same owner, and the same access (Everyone Deny ExecuteFile...).

I have also enabled inheritance in the folder I'm downloading the exe file (using the Security tab in the folder's Properties, then using the Advanced options).

I did not face this error before using NTFS Usermap. Is there something I'm missing here?

1 Answer 1


I found that in the Advanced Security Settings for all existing folders in that partition, there was a new rule denying traversal and executable permissions for everyone. Removing it solved my issue. Also, newer folders lacked that rule, which means that fixing it for all existing folders completely solves the issue.

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.