Examples below use the following users.
dc-sales-1 - UID 3021 - Unix Group g-dc-sales / GID 3002 - Primary Windows Group: Domain Users
dc-eng-1 - UID 3011 - Unix Group g-dc-eng / GID 3001 - Primary Windows Group: g-dc-eng
dc-win-1 - No UNIX attributes - Primary Windows Group: Domain Users
dc-lin-1 - Local UNIX user - UID 30031 - Unix Group dc-linux GID 3003 - Not in Active Directory
NFS Security Flavor (No POSIX ACLs, NFSv4 ACL’s not supported)
File Create from SMB:
Owner is set to the file's creator. If the Windows User does not have a UNIX equivalent, the owner will appear as nobody (UID 65534) via NFS, while the actual owner is visible via SMB.
Group is set to the owner’s primary UNIX group. This can be seen under “Leading Group” if searching for the user via VMS. If the User does not have a UNIX equivalent, then the group owner is set to nogroup (GID 65534). An ACL entry for S-1-5-88-2-65534 will be seen to represent the UNIX group nogroup when viewed from SMB.
If the parent directory that the file is created in has setguid bit, Group will be set to the Group of the parent directory.
Initial File and Directory permissions are determined by View Policy (See “Default POSIX Modebits” tab).
File Create from NFSv3:
Owner is set to the UNIX owner (as expected). If the owner does not have a Windows representation, an ACL entry for S-1-5-88-1-<UID> will be seen via SMB, where the <UID> is the numerical UID of the owner.
Group is set to the primary UNIX group (as expected). If the Group does not have a Windows representation, an ACL entry for S-1-5-88-2-<GID> will be seen via SMB, where <GID> is the numerical GID of the group.
Permissions set according to UMASK. UMASK is typically 0022, so permissions will be rw-r--r--.
File Create from NFSv4:
Owner is set to the UNIX owner (as expected).
Group is set to the primary UNIX group (as expected).
Permissions are set according to UMASK.
File Create from S3
If the User has POSIX attributes, Owner is set to the UNIX owner. If the User has no POSIX attributes, Owner will be set to the Windows SID. (This will show up as nobody to UNIX clients over NFS.)
If the User has POSIX attributes, the Group is set to the primary UNIX group. If the User has no POSIX attributes, the Group will be set to nfsnobody (gid=65534). (NOT the SID of the Windows Primary Group!)
Initial File and Directory permissions are determined by View Policy (See “Default POSIX Modebits” tab).
SMB Security Flavor
File Create from SMB:
The Owner is set to the creator of the file.
The Group is set to the Windows Primary Group. (This will usually be
Domain Users.)ACL’s are set according to inheritance rules from the parent directory.
Permissions as seen from UNIX are set according to Inheritable ACLs for CREATOR OWNER (OWNER@), CREATOR GROUP (GROUP@) and EVERYONE (EVERYONE@) without any UMASK. (Windows has no concept of UMASK). If no inheritable ACL exists for one of those, permissions will be set to 0.
ACLs are NOT visible from NFSv3 via getfacl.
ACLs are NOT visible from NFSv4 via nfs4_getfacl as NFSv4 is not supported with this Security flavor.
File Create from NFSv3:
Owner is set to the UNIX owner. If the UNIX user has no Windows equivalent, Windows will show as a SID with the numerical UID as the last digits.
Group is set to the primary UNIX Group. If the UNIX Group has no Windows equivalent, Windows will show as a SID with the numerical GID as the last digits.
UNIX permissions are set according to UMASK as applied to the Inheritable ACLs for CREATOR OWNER (OWNER@), CREATOR GROUP (GROUP@) and EVERYONE (EVERYONE@). If no inheritable ACL exists for one of those, permissions will be set to 0.
All other inheritable ACLs will apply but will not be visible via NFSv3.
chmod commands will appear to succeed (return code 0) but will not actually do anything.
File Create from NFSv4.1:
NFSv4.1 isn’t supported with SMB Security Flavor.
File Create from S3 (Requires VAST 5.0):
Owner is set to the UNIX owner if POSIX attributes exist for the user.
Owner is set to the Windows SID if there are no POSIX attributes. (Validated by looking at vid of file.)
Group is set to the primary UNIX group if POSIX attributes exist for the user.
Group is set to NOBODY (vaid=65534) if no POSIX attributes exist for user. This includes cases where the user's Windows Primary Group is a group that DOES have POSIX attributes. (Unexpected?)
If NO inheritable ACLs exist:
The Permissions are set to full_control (A::OWNER@:rwadxtTnNcCoy) for Owner. No permissions for Group or other.
If inheritable ACLs exist:
Inheritable ACLs are applied without additional modification, including intermediate directories. (i.e., no UMASK). If the CREATOR OWNER is not set or otherwise undefined, it will not be changed.
Mixed-Last-Wins Security Flavor:
File Create from SMB:
Owner is set to the Creator of file.
Group is set to the Windows Primary Group.
ACL’s are set according to inheritance rules from the parent directory.
Permissions as seen from UNIX are set according to Inheritable ACLs for CREATOR OWNER (OWNER@), CREATOR GROUP (GROUP@) and EVERYONE (EVERYONE@) without any UMASK. (Windows has no concept of UMASK). If no inheritable ACL exists for one of those, permissions will be set to 0.
File Create from NFSv3:
NOTE: Generally, it is not recommended to use NFSv3 with Mixed-Last-Wins.
Owner is set to the UNIX owner.
Group is set to the primary UNIX group.
Permissions are set according to the UMASK.
Inheritable ACLs as defined by the parent directory (if any) are ignored.
Directory Create from NFSv3
NOTE: Generally, it is not recommended to use NFSv3 with Mixed-Last-Wins.
Owner is set to the UNIX owner.
Group is set to the primary UNIX group
Permissions are set according to the UMASK.
Inheritable ACLs, as defined by the parent directory, are NOT applied to the created directory but are set as inherit-only.
File / Directory Create from NFSv4.1:
Owner is set to the UNIX owner.
Group is set to the primary UNIX group.
If ANY inheritable ACL’s exist:
Inheritable ACL’s are applied according to the parent directory.
Permissions are set according to Inheritable ACLs for CREATOR OWNER (OWNER@), CREATOR GROUP (GROUP@), EVERYONE (EVERYONE@), and UMASK. If no inheritable ACL exists for one of those, the permissions will be set to 0 for that field.
If NO inheritable ACLs exist:
Permissions will be set according to the UMASK.
NOTE: NFSv4 file and directory creation behavior is defined in the NFSv4 RFC and not unique to VAST.
File Create from S3 (Requires VAST 5.0):
Owner is set to the UNIX owner if POSIX attributes exist for the user.
Owner is set to the Windows SID if no POSIX attributes exist for the user.
Group is set to the primary UNIX group if POSIX attributes exist for the user.
Group is set to NOBODY (vaid=65534) if no POSIX attributes exist for user. This includes cases where the user's Windows Primary Group is a group that DOES have POSIX attributes.
If NO inheritable ACLs exist:
Permissions are set to full_control (A::OWNER@:rwadxtTnNcCoy) for owner—no permissions for group or other.
If inheritable ACLs exist:
Inheritable ACLs are applied without additional modification, including intermediate directories. (ie no UMASK). If OWNER@ is blank, it will not be changed.
S3 Native Security Flavor:
Note: S3 extensively uses Identity Policies, which either override or otherwise invalidate or ignore any displayed permissions from other protocols.
File Create from SMB:
Not supported
File Create from NFSv3:
Owner is set to the UNIX owner.
Group is set to the primary UNIX group.
File Create from NFSv4.1:
Owner is set to the UNIX owner.
Group is set to the primary UNIX group.
File Create from S3:
Owner is set to the Windows owner (if defined), otherwise the UNIX owner.
Group is set to the primary UNIX group (if defined), otherwise NOBODY.