Can't run executables from specific drive

[petteyg359]

"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."

My D: drive, upon which I store all my code and libraries and development stuff, has suddenly decided that new executable files are not executable. It's an internal drive partition, on the same disk as my C: drive. Everything installed prior to today runs fine, but nothing newly installed today nor any downloaded .exe files run. Double click on any .exe placed on the drive today results in the error. .exe files that are already on the drive work fine, even if moved/copied to other folders. Newly downloaded .exe files work fine from C:, just not D:. I've already checked the whole security thing, I even changed a random permission, saved, then set it back, and saved again, for the root of the drive, just to make sure I was owner with "full privileges" on every file.
Every "solution" I can find on Google is due to broken rundll, altered .exe file association, etc., and affect the whole system, not just a single drive and definitely not just new files. Any idea what the eff is going on?

 

[kaltag]

Right click on the executable (not the shortcut if you have one) and check if it has an "unblock" button on the properties tab at the bottom. If it does click "unblock" and try it again. I have run into this on vista/7/8. I have also seen UAC go haywire and cause this. Disabling UAC can fix it but I never found a proper solution that leaves it on.

 

[petteyg359]

Right click on the executable (not the shortcut if you have one) and check if it has an "unblock" button on the properties tab at the bottom. If it does click "unblock" and try it again. I have run into this on vista/7/8. I have also seen UAC go haywire and cause this. Disabling UAC can fix it but I never found a proper solution that leaves it on.

It's not that, already unchecked that box the first time I ran them. New downloaded .exe files show that warning box. That box comes up still if I haven't unblocked them or selected that "don't ask again for this file" box. The original error shows up after that. Already tried completely disabling UAC, too, to no effect.

 

[pwnmachine]

I know this is kind of obvious but have you tried running with administrator privledges? Also have you checked drive permissions?

 

[I.M.O.G.]

Can you go into properties>security>advanced on the folder/drive, then show us screenshots of the following tabs: permissions and owner.

I'd pretty much bet something has gone wrong with those. Especially if you've recently moved/copied folders around, as that has been known to cause issues like this where inheritance and permissions creation doesn't work the way you'd think it should.

 

[kaltag]

Which version of windows is this? Some quick googling turns up issues with microsoft security essentials though I've never run into any problems with it.

 

[petteyg359]

I know this is kind of obvious but have you tried running with administrator privledges? Also have you checked drive permissions?

Can you go into properties>security>advanced on the folder/drive, then show us screenshots of the following tabs: permissions and owner.

I've already checked the whole security thing, I even changed a random permission, saved, then set it back, and saved again, for the root of the drive, just to make sure I was owner with "full privileges" on every file.

Which version of windows is this? Some quick googling turns up issues with microsoft security essentials though I've never run into any problems with it.

7 Pro 64.

 

[I.M.O.G.]

It looks like you have a conflicting allow/deny for file execution.

At the top of the advanced security settings you have a deny for "traverse folder / execute files" if I'm not mistaken. It's inherited from D:\, so I would change that on D, and then your problem may go away?

You could confirm this by going to the effective permissions tab, which should detail how the rights combine and what your effective permissions are for your userid.

 

[petteyg359]

It looks like you have a conflicting allow/deny for file execution.

At the top of the advanced security settings you have a deny for "traverse folder / execute files" if I'm not mistaken. It's inherited from D:\, so I would change that on D, and then your problem may go away?

You could confirm this by going to the effective permissions tab, which should detail how the rights combine and what your effective permissions are for your userid.

No clue where that came from, but removing it seems to have fixed things. Any clue where it may have come from? I've had this happen before at home, but I've had a Windows install CD handy to just re-format and re-install.

 

[I.M.O.G.]

Usually it happens when you move or copy files around in my experience doing system administration. Sometimes things don't respond or combine the way you think they will, and the wrong rights get overwritten or inherited.

At the end of the day, NTFS has weird rules with their ACLs and inheritance compared to some other file systems.

 

[wagex]

awe man I.M.O.G. you beat me to it go back to CES
i kid i kid
i was taking a nap

 

[petteyg359]

Maybe I'm too used to Linux where permissions are sane and easily accessible via a simple ls (or getfacl, for larger systems using ACLs)... In the screenshot, my user's "allow" is AFTER the "deny". That strongly implies that it takes priority, but apparently it didn't.

 

[I.M.O.G.]

Ya, position in that list means little. In conflicts, the more restrictive permission wins out. At least i think, I would have to go back to the reference material to be sure. There's a lot of rules.

It doesn't get any less confusing when you introduce file shares, and you have a set of NTFS permissions as well as share permissions. It isn't so bad if the server is well maintained, but if you are stepping in for someone else, it can be difficult to ascertain what the intended level of access is.

 

[wagex]

Ya, position in that list means little. In conflicts, the more restrictive permission wins out. At least i think, I would have to go back to the reference material to be sure. There's a lot of rules.

It doesn't get any less confusing when you introduce file shares, and you have a set of NTFS permissions as well as share permissions. It isn't so bad if the server is well maintained, but if you are stepping in for someone else, it can be difficult to ascertain what the intended level of access is.

+1 to that where i stepped in there were two different computer companies doing work for the company that i hired in at ive been there almost a year and am still sorting things out like that, took me almost two weeks to get all the shares fixed and working right lol. though i do alot of other stuff for the company ontop of the computer stuff, im just now about to rewire/redo the whole network because it is a joke, the computer companies around here are a joke lol.

and any denies overpower the access no matter what even if it is blocked to everyone and a certain person has full access he will still be denied it has to be setup to where a group/person is allowed and a group/person is denied. rather annoying ive found my self having to walk across the building quite a few times a day because i couldnt change the settings from my rdp lol