Last revision September 20, 2010
This page describes the underlying reasons why some Linux commands and programs on the CEES computers do not work correctly with files on sesfs file shares.
With a few exceptions listed on the table of share names, all file shares on sesfs employ the Windows NTFS file permission model, which allows very fine-grained access control for specific individuals, as well as an "everyone" category. But the CEES computers are entirely Linux based and expect to see Unix/Linux permissions, which allow simpler sets of permissions for only three sets: the owner of the file; the unix account group to which the file belongs; and everyone else. Sesfs attempts to map NTFS permission settings to equivalent Unix/Linux permissions, but the mapping is imperfect and results in some anomalous behaviors.
The "owner" and "group" you see listed via ls -l on the CEES computers is irrelevant - whether you have access rights is controlled entirely by the NTFS Access Control List (ACL) that is stored with the file on sesfs. This ACL can only be viewed when the desired share is mounted directly from sesfs to a Windows computer (right click on the folder or file of interest, select Properties from the contextual menu, and then select the Security tab).
Even when you access your sesfs file share using Linux commands and programs from CEES computers, access is controlled entirely by the NTFS ACL. The Linux style permissions that you see with an ls -l command from the CEES computers are not real - they are "on the fly" conversions from the NTFS ACL that attempt to show equivalent Linux permissions for the logged-in user only! That is, unlike real Linux permissions, which are the same no matter which account runs the ls command, these "on-the-fly" conversions are specific to the account running the command. They try to represent the "closest" match to that specific account's true NTFS permissions.
NTFS ACLs can be used to give full write access to an account which is not the "owner" of the file, nor a member of the same Unix group as the file. For example, assume that "joe" is listed as the file owner, and "mary" is neither the owner nor a member of the owning group, and that both have been given write permission to a file in the NTFS ACL. The permissions that "mary" sees when running ls -l on the CEES computers may show that "others" have Linux write permissions, since that is the closest match to mary's real permissions (her account is not the owner and not in the owning group, so the only way to show write access for her in Linux is via the "others" set). The same command when run by "joe" may show that only the owner has write permission, and "others" have no permissions at all, since that is the closest match to the owning account's permissions in the ACL!
One consequence of this mis-match of permissions models is that Linux programs running on CEES computers that check the "Linux permissions" of a file on an sesfs share may get a resulting pattern that looks "odd", such as no access to the owner but write access to "others". Those programs may then refuse to complete because they are confused by these odd permissions patterns, even though in reality, the NTFS ACL on sesfs grants the needed rights to the logged-in user on the CEES computer.