Home > Storage > PowerScale (Isilon) > Product Documentation > Management and Migration > PowerScale OneFS Authentication, Identity Management, and Authorization > NFS client file access
When a file is requested for access from a client, a sequence of events occurs. The events vary depending on the type of client and the state of file permissions. In the following figure, for example, an NFS client connects to the cluster and accesses a file in each state:
Figure 21. NFS client file access sequence
In the preceding figure, the NFSv3 client connects to the PowerScale cluster, and OneFS issues a token. It is assumed that the token has the correct UID and SID. The NFS client accesses File 1, which is in a POSIX file state. The NFS client understands POSIX bits natively, so the token is compared directly to the POSIX bits to validate access, as in a standard UNIX environment.
Next, the NFS client accesses File 2, which is in a Real ACL file state. The NFS client does not understand ACL. A file with a Real ACL has a richer set of permissions, with several complicated DACLs and subheadings. OneFS must respect the granularity of the ACL file permissions. Thus, the NFS client’s token is compared directly to the Real ACL. However, if the NFS client issues an ls over an NFS export for File 2, OneFS must return POSIX bits, but these bits are for representation only and are not indicative of the actual file permissions. In fact, the permissions may even look more permissive than they are, because OneFS must approximate representing many ACLs into the six POSIX bits.