• 1 reply
  • Latest Post - ‏2012-09-21T21:47:56Z by SystemAdmin
78 Posts

Pinned topic GPFS ACLs - Windows GPFS client does not support GPFS ACLs correctly?

‏2012-09-18T10:23:54Z |
We have a file system with -k nfs4, GPFS 3.4.0-10.PTF1

At the root of the directory we have an ACL which inherits down to a certain level.
Under this level, we apply the following ACL to all subdirs.


We found that we had to add the username of all windows users into the ACL in order that files/directories will be created with the owner being the creator of the file.

I.E. without the correct username in the ACL, a 'translation to POSIX' would be: ---rwxrwx <owner> <group>. Correct username, but incorrect user permissions.
This ok for NFSv4 supporting machines, not for POSIX only machines.

If the file is copied to file system which does support NFSv4 ACLs, then you can copy file, but post-copy the user may not have permissions to access file (unless the user has group access).
If the user is in the correct group, then the user can move the file around with the shell but we know that this issue breaks the Finder in OS/X.

This only occurs when file is originated from Windows GPFS clients.
This behavior does not occur when files are originated from Linux GPFS clients or any NFS client.

I.E. If the file is originated on OS/X and written via NFS, the file is good.
If the file is originated via a Windows GPFS client then copied via NFS locally to Linux or OS/X then the file's access is 'broken' post-copy.

The only fix/workaround we can think of would be that every time we create a new Windows user, that user would have to be retrospectively added to all ACLs which currently exist on the file system. Crazy.

Can you confirm if the requirement to update all the ACLs is specific to Windows or if the ACL functionality perhaps has a 'feature' in this version of GPFS.
If so, is this fixed in a later release of GPFS?


Updated on 2012-09-21T21:47:56Z at 2012-09-21T21:47:56Z by SystemAdmin
  • SystemAdmin
    2092 Posts

    Re: GPFS ACLs - Windows GPFS client does not support GPFS ACLs correctly?

    Let me see if I understand the problem. You create a file on a node running GPFS for Windows, but then you want to access it from other nodes, and the NFSv4 translation of the Windows Security Descriptor is not what you expect/want it to be?

    On Windows, the derivation of an SD for a newly created object is actually governed by kernel security subsystem, not GPFS code. The logic there is somewhat peculiar, especially from the Unix point of view, but it is what it is. The basic Windows security model doesn't always translate well into Unix, e.g. when a file owner is a group. In general, the basic 'owner' concept is far less important in the Windows world, because the access is controlled by the SD, and the owner may or may not figure in the SD. The part that GPFS does control is the translation of an SD into an NFSv4 ACL, but it's clear to me that anything is going wrong there.

    Keep in mind that when a file has an ACL, the Posix modes word is meaningless. Mode bits are derived on the fly from the ACL, but it's an inherently lossy and imprecise conversion more anything but the most trivial ACLs. In any event, those mode bits are only there because Posix stat() has to show something. Mode bits are not consulted when access grant/deny decision is made, only the ACL is consulted.