When the requested security information is unavailable . . .

A rather peculiar situation relating to Windows security settings can occur if a copy of a file is subsequently placed into a previously shared folder that is not owned by any object (group) and/or that file is placed into the shared folder by a user that is not a member of group that has security privileges to the folder.

The highly unexpected result of this situation is that while the user is allowed to place a file (which is the same thing as "writing" to the folder) into the shared location (and it doesn't matter whether it is a new file, or a file that is replacing the same file that is already correctly shared!)  and can run/execute or read the file, other Windows users will be denied the ability to do the same.   

In the case of our software, the user will receive a message indicating that basically the program cannot be run or loaded.   Inspecting the properties of the file on the server and viewing the security tab, the rather unhelpful "The requested security information is either unavailable or can't be displayed" message is displayed:

This seems to be a  poorly designed aspect of Windows security.  This means that as a software developer, we cannot be sure that a file that we install on a remote system can be properly run by other users in a multi-user environment because of some pre-existing user/folders rights issue even though we in fact are able to write to that folder and even though it otherwise gives the appearance of working exactly as it should.  This is really not something our programs have control over and hypothetically should be none of our concern.   We should not have to double check the rights of each and every file  located on a server that we may not even have direct access to in every situation.

When we first ran into this problem simply when placing three new files into a program folder (and which we could test and run without issues but the end user ultimately could not) from a Terminal Services server (a common situation), we resolved the issue by getting access to the server, right clicking on each file and by "taking ownership" of them:

We then proceeded to add the "Everyone" group to file making sure users in the group had read/write rights.

But then more recently and on the same system (running Windows 2011 SBS Server), we replaced an existing program file via the Terminal Services server, we were again able to run and test it from that server and all seemed to be well,  but then today we were contacted by the end user who in fact could not run the recently replaced program.  Yet the file that was replaced had the exact same file name and was placed in the exact same folder that all users who had rights to that option within our software were able to previously utilize and now were being denied access.

Examining the folder's security, we noticed that there were no owners/groups assigned at the folder level.  Perhaps all of the files were all initially directly selected and shared in the folder previously (although this would not explain why a replacement file still failed nor why we could copy new files or replace existing ones in that folder at will).   By adding the  "Everyone" and "Administrator" objects/groups to the security of the folder itself, this will hopefully resolve future issues on this system of updating their installed software (and some testing conducted today placing new and replacement files into this folder and then logging into the server to view the security properties of those files indicates that it does).