Is there equivalent filesystem option on Windows like 'noexec' mount option on Linux? Is it the same if I set "Read" permission, but unset "Read & Execute" permisson on root directory (whole drive)? For the local users, but also for the LAn users accessing shared directory on Windows Server's machine.

I want to know if I can disable any kind or possibility of running programs from data drive/partition, including not to be able to create it's own subdirectory and set execute permission on it. So user must be able to read and write, but not execute any programs, including BATs. It's about security from malware, of course. Is it possible to that?


There is no analog to a "noexec" mount for filesystems in Windows. Microsoft's conception of the simple "Read" permission includes the right to execute (since execution really is just the loader reading the image into memory).

You can modify the "Advanced" version of the permission to remove (or deny) "Traverse Folder / Execute File" permission. This will prevent double-click or command-line execution of .EXE files. .BAT and .CMD files will not execute from a double-click in Explorer, but they will still execute from a command prompt or using the syntax "CMD /c " from Start / Run.

Changing the permission breaks the "analogy" of a "noexec" mount since "noexec" doesn't require any modifications to the permissions of the mounted volume.

You'd be better off looking at Software Restriction Policies as a way to accomplish what you're looking for. This facility changes the behaviour of the API used to execute programs to restrict the paths (or by digital signature or cryptographic hash) from which programs can be executed. Assuming your local users do not have "Administrator" rights, this functionality would be effective, to some extent.

Ultimately, though, if there's any filesystem location on the computer where the user is permitted to both write files and execute, the user could copy programs from the restricted-execution paths to this location and execute the program from there. You would need to be very diligent to insure that there are no such locations.

Alternatively, Software Restriction Policies can be used in a "default deny" mode, wherein only specified paths (or digital signatures or cryptographic hashes) will allow execution. This is also fairly difficult to setup, since you need to test all your applications to be sure that their execution is successful.

You don't mention what version of Windows you're talking about. For Windows 7 and Windows Server 2008 R2, Software Restriction Policies is part of AppLocker and the functionality is similar.

  • This is inaccurate. Right click a file, go to the Security tab, click Advanced, then Edit, then Edit (again), and you will see the full list of permissions. Note that "traverse folder / execute file" is distinct from "list folder / read data."
    – Mark Sowul
    Dec 23 '09 at 1:04
  • AppLocker is improved in many ways though, making deployment and implementation much easier to manage... you can roll it out in audit mode only for instance so it'll log but not actually block for the admins to analyze after a while. Dec 23 '09 at 1:43

Go to security options for the drive (right-click, security tab), then click "Edit"; if you want to prevent standard users from executing anything on the drive, you can select the "Users" entry and uncheck "Read & execute" and leave "Read" checked.

  • 1
    I don't know about later versions but up to 2003 at least that doesn't work. You can remove that right all you like but freestanding executables (at least) will still run. Dec 23 '09 at 2:51
  • I just tested on XP and it worked fine. Right-click an exe, uninherit the permissions, leave Read enabled but not Read & Execute. Try to run it and it will give you an access denied error.
    – Mark Sowul
    Dec 23 '09 at 12:20
  • +1 - This is eating at me so I've dropped an edit onto my original posting to make it more accurate. I stand by the fact that there isn't an analog to the "noexec" mount like the poster was asking for, though I'll (happily) concede that you can mangle the NTFS permissions on executibles to prevent execution. Dec 23 '09 at 16:11
  • You're right that in many, software restriction is the better option, but given the use case (file server) I don't it's as useful, since all the clients would need to have the restriction set up, whereas altering the server ACLs only needs to be done there. Just make sure the user doesn't have permission to change the permissions (which would be the case if you uncheck "Read & execute" but leave all the modify permissions.
    – Mark Sowul
    Dec 23 '09 at 16:46

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.