File sharing best practices guide - Hewlett Packard Enterprise · File sharing best practices guide . HPE 3PAR File Persona . ... (S MB, NFS, FTP, and Object Access API), where SMB

File sharing best practices guide HPE 3PAR File Persona

Technical white paper


Contents Introduction ................................................................................................................................................................................................................................................................................................................................................... 3

Audience .................................................................................................................................................................................................................................................................................................................................................... 3 User interfaces ..................................................................................................................................................................................................................................................................................................................................... 3

Multiprotocol in File Persona......................................................................................................................................................................................................................................................................................................... 3 Authentication ...................................................................................................................................................................................................................................................................................................................................... 3 Authentication provider stacking order ........................................................................................................................................................................................................................................................................ 4 User identity mapping .................................................................................................................................................................................................................................................................................................................. 5 External mapping service RFC2307 ................................................................................................................................................................................................................................................................................ 6 Dedicated security modes ..................................................................................................................................................................................................................................................................................................... 12 Authorization ..................................................................................................................................................................................................................................................................................................................................... 14

Server Message Block (SMB) share management ................................................................................................................................................................................................................................................. 19 Persistent Handles (PH) ......................................................................................................................................................................................................................................................................................................... 20 File locking ........................................................................................................................................................................................................................................................................................................................................... 21 SMB limits for File Persona ................................................................................................................................................................................................................................................................................................... 22

Network File Services (NFS) share management ................................................................................................................................................................................................................................................... 22 Share configuration ..................................................................................................................................................................................................................................................................................................................... 24 Managing NFS permissions.................................................................................................................................................................................................................................................................................................. 24 File locking ........................................................................................................................................................................................................................................................................................................................................... 25 NFS limits for File Persona .................................................................................................................................................................................................................................................................................................... 25

Object Access API share management ............................................................................................................................................................................................................................................................................ 25 File locking ........................................................................................................................................................................................................................................................................................................................................... 26

File Transfer Protocol (FTP) share management .................................................................................................................................................................................................................................................. 27 Troubleshooting ................................................................................................................................................................................................................................................................................................................................... 28

Overview ................................................................................................................................................................................................................................................................................................................................................ 28 NFS troubleshooting .................................................................................................................................................................................................................................................................................................................. 28 SMB troubleshooting ................................................................................................................................................................................................................................................................................................................. 28 Object Access API troubleshooting .............................................................................................................................................................................................................................................................................. 28

Appendix...................................................................................................................................................................................................................................................................................................................................................... 29 SMB ............................................................................................................................................................................................................................................................................................................................................................ 29 NFS ............................................................................................................................................................................................................................................................................................................................................................. 29

Revision history ..................................................................................................................................................................................................................................................................................................................................... 30 Related documentation .................................................................................................................................................................................................................................................................................................................. 30

Technical white paper Page 3

Introduction The modern IT needs for their data centers to deploy, serve, manage and report on different tiers of business applications, databases, virtual workloads, home directories and file sharing all at the same time, co-locate multiple systems, and share power and energy. This is true for large as well as small environments. Modern IT would like to consolidate as much as possible to minimize cost and maximize efficiency of their data centers and branch offices. HPE 3PAR StoreServ is highly efficient, flash-optimized storage engineered for the true convergence of block, file, and object access to help consolidate diverse workloads efficiently. HPE 3PAR OS and converged controllers incorporate multiprotocol support into the heart of the system architecture.

Audience This white paper provides best practices for file sharing when using HPE 3PAR File Persona. It is intended to assist the System Administrators, Solution Architects, and Professional Services Consultants who design, deploy, and administer the HPE 3PAR StoreServ storage system in a file sharing environment.

User interfaces There are three unified management interfaces available for block and file administration of HPE 3PAR StoreServ—the HPE 3PAR StoreServ Management Console, HPE 3PAR OS CLI and the HPE 3PAR StoreServ WSAPI for programmatic management. Unless otherwise stated, all tasks can be performed with both the HPE StoreServ Management Console (SSMC) and the HPE 3PAR OS CLI. Refer to the HPE 3PAR OS CLI administrator’s manual and the HPE 3PAR StoreServ Management Console online help for instructions on how to perform the tasks described at a conceptual level in this guide.

The third interface, Web Services Application Programming Interface (WSAPI) is primarily focused on providing an industry-wide adopted protocol to manage and control File Persona and Block Persona for HPE 3PAR StoreServ arrays. This allows customers to programmatically access and automate the provisioning and management tasks for file shares hosted on the array.

Multiprotocol in File Persona For HPE 3PAR File Persona, multiprotocol means that different directories are shared using different (multi) protocols. For instance, directory “Marketing” is shared using the SMB protocol, directory “Engineering” is shared using the NFS protocol and directory “Cloud” is shared using the Object Access API. In the context of this white paper cross-protocol means that the same directory is shared using multiple protocols, for instance the directory “Marketing” is shared using the SMB as well as the NFS protocol and users can access the same files from multiple protocols concurrently. Prior to HPE 3PAR OS 3.3.1, File Persona supports cross-protocol for file shares for specific use case scenarios, where directories are shared out to one protocol as the writer protocol and other protocols as read-only. This multiprotocol access method is now known as the “Legacy” security mode in HPE 3PAR OS 3.3.1. Please refer to Setup Guide for HPE 3PAR File Persona in a Cross-protocol Environment for more information on how to configure this.

HPE 3PAR OS 3.3.1 introduces a new security mode, called “NTFS”. It enables near native experience for Windows® clients for ACL inheritance, ACL setting, default permissions and permissions enforcement, allowing simultaneous read/write access for both Windows and POSIX clients. When using the NTFS security mode, share mode locks applied by Windows clients are not only honored by other Windows clients but across all protocols.

The Legacy and NTFS security modes are set at the File Store level.

Authentication Authentication is a process of validating user/group credentials to an account name and password stored in a name service. As part of this process name resolution happens by performing a lookup for a user or group based on a property such as SID, Name, or UID/GID/SID.

Microsoft® Windows uses security identifiers (SIDs) to identify users and groups uniquely. An example of a simple SID is S-1-1-0, which is the SID for the Windows group “Everyone”. Linux®/UNIX® uses user IDs (UIDs) and group IDs (GIDs) as integer values to identify users and groups uniquely. In a cross-protocol environment, there must be a mapping between those schemas using an identity mapping service to evaluate the access privilege of any files or directories accessed from any protocol.

http://www.hpe.com/support/3PARshareconfig



Local authentication Local authentication will often be used in smaller Windows or Linux/UNIX environments, please note that this does not refer to the typical Linux local authentication that most (Linux/UNIX) administrators are familiar with. Local authentication here refers to the Local Users & Groups that reside and are restricted to a single HPE 3PAR storage array running File Persona. Each File Persona node maintains a replicated copy of the local user database in an HPE 3PAR storage array.

Note When creating local users or groups, only UID/GID values in the range of 1,000 to 65,635 are allowed.

Local users are authenticated using NTLMv2 authentication by default for clients communicating over SMB2 or beyond. The password is stored in encrypted form in the local user’s database. UIDs and GIDs are system generated and assigned automatically if not specified during user creation. The storage administrator should make sure that IDs are unique across the name services.

Best practice Local authentication as the single authentication method in the stack is only suitable for small environments (single array with File Persona, not more than a couple of hundred user accounts).

Active Directory Active Directory (AD) is a directory service, primarily used in Windows environments, but Linux/UNIX environments can also use it for name lookups and authentications for user accounts and groups. All user name lookups are stored in the Active Directory name cache on the File Persona node. This cache is referenced or populated for every user name request and will be cleared when File Persona is restarted. The computer account and Kerberos credentials are updated as needed. File Persona must be joined to a single AD domain, so all the nodes running File Persona will be joined to the same AD domain. All name resolutions and authentications for File Persona are limited to that AD domain and all trusted domains.

Active Directory is the most commonly used provider for authentication when accessing shares using SMB only or using cross-protocol.

Lightweight Directory Access Protocol (LDAP) LDAP is most commonly used in Linux/UNIX environments, where users connect to file shares on File Persona over NFS protocol. The LDAP schema attribute used by File Persona depends on the schema template specified. The File Persona SMB server can be configured to use either Samba or POSIX schema, but only one schema at a time. There is no LDAP provider cache similar to the AD provider cache, as only user and group information is cached, so only access through Linux commands or cross-protocol name lookups will benefit from it.

LDAP authentication can very well be used for multiprotocol or cross-protocol. However, when SMB clients (most likely Windows clients) are present, an AD domain will probably already be available making AD the preferred choice for authentication. When POSIX based clients are used or when NFS is the primary protocol in use and there is no AD available to integrate, LDAP would be a viable alternative for authentication.

Best practice There may be more than one type of authentication method used within an organization’s environment, but Active Directory is the most versatile option to be used for File Persona. Use local authentication mainly for small number of user environments, not more than a couple of hundred user accounts.

Authentication provider stacking order Active Directory, LDAP and Local Users & Groups are used for authentication only and are defined by the authentication provider stacking order configured for the File Persona. The authentication provider stacking order determines which name services are searched first. A name service search is complete when the matching name is found. The second name service is not queried until the search of the first provider is completed.

The authentication provider stacking order can be configured via SSMC after enabling advanced options in the Configure File Persona menu. Active Directory and Local Users & Groups are in the default stack order (see figure 1). The Local Users & Groups must be listed in the provider order, while LDAP and Active Directory are optional.


Best practice Authentication provider order should include only authentication types that are configured on the system. E.g., if Active Directory is listed in the order, it must be configured on the HPE 3PAR system running File Persona. It is most efficient to order the most frequently used services first.

To show the configured provider order on the CLI, use the command showfs –auth. Note that the stack order is configured separately from the authentication methods, and if a method is not in the stack, users will not be able to authenticate using that method.

Figure 1. Configuring the authentication provider stacking order

Note The authentication and authorization method used for HPE 3PAR File Persona is separate from the security method used for management of the HPE 3PAR StoreServ array (Management Console and CLI). For instance, management array access can be using local authentication and authorization method (on the HPE 3PAR StoreServ nodes), while HPE 3PAR File Persona is using Active Directory for authentication and authorization.

User identity mapping A common problem for cross-protocol environments is a mismatch in user identity formats. User mapping plays a very important role for shared data access in a cross-protocol environment, where usually the mapping is done between Windows users and Linux/UNIX users. To configure a system so that the same user name or group name maps to a specific UID/GID in POSIX, and a specific SID in Windows, user identity mapping is an essential requirement for customers accessing same file shares from multiple protocols at the same time.

HPE 3PAR File Persona supports many access protocols (SMB, NFS, FTP, and Object Access API), where SMB uses SID to represent the user’s identity and POSIX access protocols (NFS, FTP, and Object Access API) use UID and GID. File Persona stores a file object’s ownership in UID/GID format, and its permissions in a Converged ACL format (NFS4-like) that uses Universal Path Names (UPNs) to identify users and groups in the ACEs’ principals. To support cross-protocol access, File Persona needs to convert those file objects permissions to a synthetic native ACL using the valid identity format of the accessing protocol, and identify the user accessing the file object also using the native identity format (UID/GIDs or SID). Typically, Windows clients use Active Directory (AD) as authentication provider, AD always stores SID as identity unless it’s also configured to store Linux/UNIX attributes (RFC2307 mode). Typically, POSIX clients use LDAP as authentication provider, where LDAP normally stores UID/GID as the identity under POSIX schema unless it’s configured with SAMBA schema.


Prior to HPE 3PAR OS 3.3.1, it was a requirement to configure external mapping service by configuring AD for authentication in RFC2307 mode, or LDAP with SAMBA schema, to be able to build identity mappings which provided consistency for cross-protocol access. Starting on 3.3.1, File Persona introduces a new internal user mapping, Static and Dynamic, which can be used instead or in addition to the external mapping service to obtain consistent identity mapping in a cross-protocol environment. Figure 2 shows the supported user name mapping services available with File Persona.

Figure 2. User name mapping services supported with File Persona

External mapping service RFC2307 User identities can be fully managed with SIDs, UIDs, and GIDs within Active Directory by enabling RFC2307 attributes, thus a Windows user will use the SID, and NFS clients can be configured to use Active Directory as an authentication source for UID and GID. HPE 3PAR File Persona supports the user mapping between the Windows users and Linux/UNIX users via RFC2307 as an external name mapping service. If the RFC2307 ID mapping setting is enabled on File Persona, users accessing the shares from the clients still identify themselves by name (UPN), or SID (SMB client) or UID/GID (POSIX client). File Persona, during authentication, is using the values in the AD to build the full identity of that user with a corresponding UPN, SID, UID/GID that will be consistent for access from either protocol.

Figure 3. External user mapping using RFC2307


If user mapping between Active Directory and LDAP providers is not used, File Persona has the following options to represent user identities for multiprotocol access:

• AD provider in RFC2307 mode (provisioned): If File Persona is configured to use RFC2307, it uses UID/GID from AD for POSIX user identity.

– Pros:

Both clients and File Persona share the same identity presented from AD provider and have consistent user and group information across multiple machines.

Central administration of users (UID, Login Shell, Home Directory, Primary Group) and groups (GID) directly in Active Directory.

No need for keeping track of IDs manually, when using the default Microsoft tools. E.g., the next free UID and GID is stored directly in Active Directory and will be incremented when creating a new user or group.

– Cons:

RFC2307 user and group attributes in AD provider need to be configured with UID/GID. Both SMB and POSIX clients would need to use AD as a single authentication provider.

If a user object is not configured with UID/GID values when RFC2307 is enabled, while that user may have read access, the user won’t be able to write.

• AD provider not configured in RFC2307 mode (unprovisioned): File Persona synthesizes the UID/GID for POSIX user identity.

– Pros: No explicit configuration required.

– Cons:

POSIX clients would need to use the same UID/GID as synthesized by File Persona.

The synthesized UID/GID is unique for that HPE 3PAR array running File Persona and consistent across the Virtual File Servers (VFS). This makes it difficult to use the unprovisioned mode when using cross-protocol access, as the mapping of users from different protocols must be done manually and is prone to administration errors.

• LDAP provider using Samba schema: File Persona uses the SID provided by LDAP for SMB user identity.

– Pros: Both clients and File Persona share the same identity presented from LDAP provider.

– Cons: User and Group attributes in LDAP provider need to be configured with SID. Both SMB and POSIX clients would need to use LDAP as a single authentication provider.

• LDAP provider using POSIX schema: File Persona synthesizes the SID for the user identity.

– Pros: No explicit configuration required.

– Cons: Windows clients would need to use the same SID as synthesized by File Persona.

Best practice If RFC2307 has been enabled, each user accessing shares hosted by File Persona must have a UID/GID specified in AD (even if they are not using cross-protocol). RFC2307 configuration for File Persona is applicable to entire array, i.e., it’s applicable to all the VFSs or none in an array.


Enabling RFC2307 on File Persona:

Use the setfs rfc2307 {enable|disable} command to set the RFC2307 behavior, or use SSMC to enable/disable it.

Figure 4. Enabling RFC2307

Caution Changing the RFC2307 setting after files have been written to the respective file shares can lead to loss of access (there is no loss of data) to those files. This is because the UID or GID that provided access to the resource is no longer bound to the same name.

When going from unprovisioned mode to provisioned mode (enabling RFC2307), this issue can be recovered from or resolved by:

1. Returning the UID/GID mapping setting to its previously assigned value (setfs rfc2307 enable|disable).

2. Assigning the UID and GIDs that were previously synthesized by File Persona, to the associated AD users and group RFC2307 attributes.

3. Change the ownership, group, and ACLs on all files to reflect the new UIDs and GIDs being assigned. There are no tools provided to perform these translations.

When going from provisioned mode to unprovisioned mode (disabling the RFC2307) only options 1 and 3 can be used. Either the setting needs to be returned to its previous state before more files are created in this state, or change the Active Directory mode and ACLs on all files to reflect the new name to ID mappings.

Internal static mapping service If RFC2307 is not used with Active Directory and cross-protocol access is required for same files from SMB and NFS clients, then File Persona also provides an internal name mapping service on the HPE 3PAR system using Static and/or Dynamic mapping. In static user mapping, an explicit user identity mapping is defined in a mapping file on File Persona to map user and group identities from both Active Directory and LDAP providers. The following are the minimum requirements for File Persona identity mapping to be configured and used:

• StoreServ InForm OS 3.3.1

• OpenLDAP for Linux Authentication

• Active Directory for Windows Authentication

• HPE 3PAR CLI Client (used to import user map)

• SSMC 3.1 (CLI can be used instead, however, SSMC makes it much easier to configure cross-protocol environment for File Persona)


Table 1. The static mapping service has two mapping types, unidirectional and bidirectional

Unidirectional mapping Bidirectional mapping

The user identity is replaced with another one; a Windows user mapped to an LDAP user will use the identity provided by the LDAP provider when interacting with File Persona.

User identities are merged with each other; a Windows user will keep the SID provided by AD and a Linux user would keep his UID and GID provided by LDAP when interacting with File Persona, but they are considered the same user.

Map multiple identities to a single identity, for example if multiple Windows users are generating content for an application that is running on Linux.

Map user identities with different name, explicitly specify a user identity to be mapped to one from a different provider. Example: Windows user “johnw” is the same user as “john” in Linux.

Groups and memberships in one source, when LDAP only contains user accounts; groups and group memberships need to be solely managed in Active Directory.

Map group identities with different name, explicitly specify a group identity to be mapped to one from a different provider. For example, “Engineering” group in Windows is the same as “Engineers” group in Linux.

Internal dynamic user mapping service The internal dynamic user mapping is an automatic bidirectional mapping where user identities are automatically matched (by user name) between different authentication providers. Upon successful authentication, a wild card rule is used to provide dynamic mapping of users with the same name in different providers. The identities are automatically merged if a mapping is found; If there is no mapping found for the “from user” in the “to user” provider, the missing identity is synthesized.

Figure 5. Dynamic user mapping

Note If there is no mapped user at the time of lookup, a synthesized identity will be used. If a mapping is configured later, to ensure continued access ‘showfs –usermap’ can be used to identify the synthesized identity, so either object ownership or mapped identity can be configured accordingly.


Best practice When using cross-protocol access the internal user name mapping method is non-intrusive for existing environments, as it will map between AD and LDAP providers without any reconfiguration. It’s recommended to use the internal name mapping services if File Persona has not been configured to use any name mapping yet.

Managing the internal mapping service To manage the internal mapping service, use the CLI (support for managing it using SSMC will be supported in a future release of the SSMC software) commands.

To verify if user mapping has been enabled run showfs -usermap, the output looks like:

Mapping Enabled : true

State : OK

Health Description : Component is healthy.

Corrective Action : --

To show effective mapping for user “user_2” run showfs -usermap -d -username user_2@WIN:

SID : S-1-5-21-2943099029-2375420575-3763763779-432659

UID : 1500

GID : 1100

UPN : [email protected]

NetBIOS Name : WIN

SAM Account Name : user_2

Domain : CN=user_2,OU=Users,DC=WIN,DC=LOCAL

Primary Group Name : group_2

Alias Name : --

Map Found : true

Primary Group SID : S-1-5-21-2943099029-2375420575-3763763779-512

Additional Info : --

Password Expired : false

Password Never Expires : true

Prompt Password Change : false

User Can Change Password : true

Account Disabled : false

Account Expired : false

Account Locked : false

Mapping From : WIN\user_2

Mapping To : LDP\some_user

Mapping Type : ==


Administrators can import the user mappings using a file containing the mapping rules, where the users will be represented as either domain\user or user@domain, using either of the following rules:

Table 2. Name mapping rules

Example Rules operators Description

WIN\jdoe => LDP\johnd Replace rule ‘from user’ (=>) ‘to user’

Upon successful authentication, ‘WIN\jdoe’ is replaced with identity of ‘LDP\johnd’.

If user ‘WIN\jdoe’ accesses an SMB share, every interaction with the file system is done with the user ‘LDP\johnd, including group memberships of user ‘LDP\user_7’. In this case the SID of the Windows user is not used. Instead if the LDAP user has a SID it’s used. If the LDAP user doesn’t have a SID, a SID is synthesized based on LDAP user’s UID/GID.

WIN\joy == LDP\bob

WIN\grp_sales==LDP\grp_engg

Join/merge rule ‘from user’ (==) ‘to user’

Upon successful authentication, ‘WIN\joy’ is merged with identity of ‘LDP\bob’.

If user ‘WIN\joy’ accesses an SMB share, the SID from Active Directory is used and the UID/GID of ‘LDP\bob’ for POSIX transactions.

If user ‘LDP\bob’ accesses an NFS share, the UID/GID of LDAP is used and the SID of ‘WIN\user_2’ for SMB transactions.

If primary groups of users do not have the same name, so they need to be statically mapped as well, otherwise group identities are synthesized by File Persona.

Note: No group mappings are supported by File Persona other than primary groups for users mapped with join/merge rules.

*==* Dynamic mapping fallback rule for matching users (==)

Upon successful authentication, users with matching user name in Active Directory and LDAP are merged with each other.

If user ‘WIN\finch’ accesses an SMB share, the UID/GID of ‘LDP\finch’ is used for POSIX transactions.

If user ‘LDP\finch’ accesses an NFS share, the SID of ‘AD\finch’ is used for SMB transactions.

Best practice The replace rule is only usable in unidirectional mapping scenario for explicit user mapping. This rule is not recommended for wild card mapping.

The join/merge rule is good for bidirectional mapping scenario for explicit user mapping.

The wild card rule is recommended to be used as the last entry of the user mapping file to map the matching user names between Active Directory and LDAP, after all the explicit static user mapping entries have been processed.

Example of a user mapping file, based on the examples used in Table 1:

Figure 6. Example of a user mapping file


Rules for setting up and maintaining a user mapping file:

• A user mapping file is parsed by the system from top to bottom (indicated by the evaluation direction arrow to the left of Figure 6).

• User mapping stops after the first match.

• It is most efficient if exceptions in all users/groups from Windows and Linux that will use cross-protocol access are mapped first (like mismatched names in Windows and Linux, or Unidirectional mapping etc.). The rest of the users/groups that have exact match in Windows in Linux will be mapped automatically by Dynamic user mapping *==*

Currently, the User mapping file can be imported to file persona only via HPE 3PAR CLI Agent. The easiest way to import the user mapping file is to create it in text editor, like Notepad, copy it to inside of “bin” directory of HPE 3PAR CLI Agent installation location (by default, it is installed at “C:\Program Files (x86)\Hewlett-Packard\HP 3PAR CLI\bin\”) and run the following command to import the file (file name is Case sensitive):

setfs usermap –importconf <filename.extension>

Dedicated security modes HPE 3PAR OS 3.3.1 introduces dedicated security mode, which enables near native user experience for the preferred protocol. It determines the primary type of security enforced on files and folders in a File Store and restricts permission changes from non-preferred clients to prevent fidelity loss. These security modes are enabled at the File Store level.

Best practice When cross-protocol access is required, the internal mapping service is the recommended mapping option as it is less intrusive (compared to external user mapping) and very flexible. A combination of static and dynamic user mapping can be used in the user mapping file, which is evaluated starting at the first line, down to the bottom of the file. A typical cross-protocol use case for the replace rule is a group sharing scenario. A typical cross-protocol use case for the merge rule or fallback rule is a home directory scenario.

If RFC2307 needs to be enabled, this should be done only during initial network configuration. Changing the setting by enabling or disabling RFC2307 after the file shares are in use will affect user and group access to their data.

NTFS security mode The NTFS security mode is preferred for the SMB protocol and enables near native Windows user experience enforcing NTFS security behavior on files and folders in a File Store. These files and folders will maintain full fidelity NTFS ACLs and default permissions will always follow Windows inheritance rules. This security mode also allows read/write access to all protocols for any shared folders with the support of cross-protocol shared mode and exclusive locks, however permission changes are only allowed to SMB clients, other protocols can access the file and directories as read/write but are not allowed to make permission changes. File names can be case insensitive as expected by SMB clients.

Best practice Use NTFS security mode for a Windows dominant environment and when file sharing with read/write access for the same files is required from multiple protocols.

The defaults permissions at the shared root folder for NTFS security mode are:

Owner: root, Group: Administrators@B-LOCAL_CLUSTER

A:fd:OWNER@:rwaDxtTnNcCoy

A:fdg:GROUP@:rwaDdxtTnNcCoy

A:fdi:CREATOR^OWNER@:rwaDdxtTnNcCoy

So the default ACL in NTFS mode allows the following users to change permissions to give access to other users and/or access from other protocols clients.


File Persona administrators:

• The node’s root user from Local Users & Groups has full control

• The node’s members of local group Administrators@B-LOCAL_CLUSTER have full control

Windows clients administrators:

• SYSTEM@NT_AUTHORITY (Windows equivalent to root) has full control

• Members of Window’s Client Administrators group have full control

NFS clients cannot change permissions (independent of default AC—by definition of the NTFS Security Mode).

The permissions are inheritable and when a new share directory is created (nested shares) it follows the security mode’s inheritance rules. If the directory existed prior to share creation, the ACL is not overwritten as it assumes current (defaulted or crafted) ACL, unless user explicitly overwrites.

Managing share folder permissions in the NTFS security mode The HPE 3PAR CLI can be used only to create new share root folders (creatfshare –sharedir), which will inherit permissions as described, as well as to manage the permissions at the share root folder level (setfshare –acl | -owner |-group). In the NTFS security mode, setfshare –chmod is not allowed. Other children files and folders can be created in the share from the protocol clients only, and the default permissions will also follow the security mode’s inheritance rules, i.e., in the NTFS security mode, NTFS inheritance rules will be followed, independent of the client’s protocol.

Windows clients will experience usual behavior and can use the native Windows ACL semantics to manage permissions. Default permissions for new file objects are as expected by Windows clients, where POSIX clients can view the permissions, however they are not allowed to change the permissions (chmod/chown/chgrp/setfacl). The usage of “no root squash” (disabling mapping requests from UID/GID 0 to the anonymous UID/GID) for NFS exports is not allowed when using NTFS security mode (this option is grayed out during NFS share setup in SSMC when using NTFS security mode for cross-protocol sharing). The permission enforcement for Windows clients follows NTFS ACL enforcement rules where POSIX clients get the translated permissions from the NTFS ACL to a POSIX ACL to follow POSIX enforcement rules. This differentiates File Persona from other solutions, as they convert only to Linux/UNIX mode bits. As File Persona converts to the POSIX ACLs it provides higher fidelity permissions on Windows, including named ACEs for users and groups, and POSIX Default ACLs (inheritable ACLs).

Legacy security mode The legacy security mode is for backward compatibility where files and folders will have the precedence for either NTFS ACLs or POSIX ACLs, based on permissions last applied. Default permissions for new files follow Windows rules for SMB clients and POSIX rules for NFS clients. This allows for read/write access for a single protocol and a read-only access for other protocols. Please note that the read/write from a single protocol restriction is not automatically enforced by the system, but is the supported configuration rule that must be followed by administrators. Please refer to the Setup Guide for HPE 3PAR File Persona in a Cross-protocol Environment for more information on how to configure this. File names can be case insensitive for SMB clients and case sensitive for NFS client (caution: files can be overwritten if file name in the same directory only differ in case). In case of an upgrade to HPE 3PAR OS 3.3.1 all existing File Stores will be marked as “Legacy”.

Best practice Use the Legacy mode for backwards compatibility only or for single protocol read/write sharing for NFS/Object access. When NFS (Linux/UNIX platforms) sharing is used exclusively, the Legacy security mode is a good alternative for the NTFS security mode. When Legacy mode is going to be used with cross-protocol, refer to Setup Guide for HPE 3PAR File Persona in a Cross-protocol Environment for further information.

When using Legacy security mode, managing share root folder permissions via the HPE 3PAR CLI should be limited to the chown, chgrp and chmod interfaces: setfhare –owner | -group | -chmod. The option to change ACLs using the HPE 3PAR CLI should be avoided in the Legacy security mode (setfshare –acl).

Figure 7 shows when a default ACL will be applied (or not) while creating a file share. When a new folder is being shared the default ACL will be applied. When the folder to be shared already exists but has only hidden files (it is considered to be empty), the default ACL for the protocol will be applied. When the folder to be shared already exists and has non-hidden files, the folder will be shared without modifications to the existing ACL.




Figure 7. Decision tree when creating a file share in legacy mode

Best practice HPE strongly recommends that the system administrator examines the ACL and make any changes to comply with the organization’s requirements, prior to making the share available to others.

Use the Legacy mode only for backwards compatibility or when creating a file share, which will be primarily used for NFS/Object Access as when using the NTFS security mode, the permissions can only be changed using a Windows client. In Legacy mode permissions of file objects inside the share should only be changed from the POSIX clients using Linux/UNIX interfaces.

Authorization Authorization is a process used to verify what effective permissions a user (or group) has on either the file share or on files and folders. Authorization is performed by comparing user account or member names of a group with the permissions on file storage resources such as shares, files, or directories. Only authorized users (or groups) are allowed to access shares or any files or folders, others are denied access.

Most file systems have methods to assign permissions or access rights to specific users and groups of users. These systems control the ability of the users to view or make changes to the contents of the file system. These methods use share-level permissions or File/Folder-level access control lists (ACLs) to describe which user (or group) has specific rights on files and directories.

Share-level permissions To interact with a share, the user must have the appropriate share permissions to be able to map/mount the share from an SMB or NFS client. In HPE 3PAR File Persona, permissions are set on the file share using the HPE StoreServ Management Console (SSMC) or the following CLI commands:

• createfshare smb/nfs/obj –allowperm/denyperm <permlist> • createfshare smb/nfs/obj – allowip/denyip <iplist>

The options allowperm and denyperm specify a user’s permission level in accessing the share and are relevant only to SMB users.

Note The allowperm option of the createfshare command controls the share permissions. In addition, a user needs to have access to the folder associated with the share to be granted access. Use the acl/mode/owner/group option in the setfshare command to control the share folder permissions.


These types of permissions are called share permissions and they are separate from the ACLs on files/folders. Following are some facts about the file shares on File Persona:

• Share-level permissions include Full Control, Change, and Read

• The effective rights of a user are the combination of share and Windows ACLs with the most restrictive permissions

• No access takes precedence over any granted permissions, file, or share

• “Deny” permissions generally take precedence over “allow” permissions

• Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group)

Share permissions for different NFS versions have a little different behavior (failure of the mount request versus successful mount). If an NFS client is not configured to have access to the share:

• NFSv3: The mount request will fail

• NFSv4: The mount request will succeed but the NFS client will get “access denied” when trying to access any files/directories in the share

The net result of the share permissions is the same; the client has no access to the data on the share.

Note The share level permissions are not inherited by the ACLs, which define the permissions to files and folders under that share.

Types of access control lists An access control list (ACL) is a list of access control entries (ACE) and controls permissions for files and folders. Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. There are three types of ACLs: NFSv4, Windows, and POSIX ACLs (the mode bits and POSIX ACL—if present—together are used to enforce permissions to file objects when access is via the POSIX protocol). However, File Persona will convert these to store a Converged ACL on disk (the Converged ACL is NFS4.1-like and stores UPNs for principals). When files or directories are accessed by the users, File Persona will convert the stored Converged ACLs to the ACLs supported by the respective client accessing the files or directories e.g., convert Converged ACLs to POSIX ACLs for an NFSv3 client, convert Converged ACLs to Windows ACL for a Windows client. The converged ACLs are explained later in this document. The NFSv4/Windows ACLs are more fine-grained (high fidelity) than POSIX ACLs.

POSIX ACLs Linux/UNIX-like and otherwise POSIX-compliant systems, including Linux-based systems, have a lower-fidelity system for managing the individual file permissions read, write, and execute (rwx). This system is managed in three distinct scopes or classes, which are known as owner, group, and others. The three permission bits can be set for each user class, giving permission to read (r), write (w), and execute (x). When a file is created on a Linux/UNIX-like system, its permissions are restricted by the umask of the process that created it. Each class can have one of the following permissions:

• The read permission when set on a file, grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory, but not to find out any further information about them such as contents, file type, size, ownership, permissions.

• The write permission when set on a file, grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files.

• The execute permission when set on a file, grants the ability to execute a file. This permission must be set for executable programs, including shell scripts, in order to allow the operating system to run them. When set for a directory, this permission grants the ability to access file contents and meta-information if its name is known, but not list files inside the directory, unless read is set also.

In addition to these traditional minimal ACLs (Linux/UNIX mode bit), the File Persona does support the extended ACLs (i.e., named user or group ACLs), which can be set and viewed over NFSv3 using “getfacl” and “setfacl” by resolving the UID to the actual user name.


NTFS ACLs Microsoft Windows NT and its derivatives (including Windows 2008, 2012, etc.), use access control lists (ACLs) to administer a more rich and varied set of permissions. These NTFS ACLs have more, fine-grained, permissions: full control, modify, read, execute, list folder contents, write, and special-inherited permissions.

An ACL is an ordered list of ACEs (Access Control Entries). Each ACE contains the following:

• A SID (Security identifier) that identifies a user or group

• An access mask that specifies access rights

• A set of bit flags that determine whether child objects can inherit the ACE

• A flag that indicates the type of ACE

ACEs are fundamentally alike. What sets them apart is the degree of control they offer over inheritance and object access. Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: Discretionary Access Control Lists (DACLs) and System Access Control Lists (SACLs). Together with the owner’s identity (owner and group SIDs), a DACL and a SACL form the NTFS Security Descriptor that Windows uses to enforce access permissions to a file object. In this document when we refer to the Windows ACL, we refer to the DACL in the Security Descriptor, unless otherwise specified. Refer to the Windows Authorization page on Microsoft’s website for more information on DACLs, ACEs, and SACLs.

File Persona converts a Windows DACL into a best approximation in the Converged ACL (with UPNs) which it stores on disk (in NFS4.1-like format). Then it converts back to a Windows ACL when requested access by an SMB client. For example, when an SMB client requests access to a file or folder the File Persona converts the NFSv4.1 ACL stored on disk to a Windows security descriptor, which contains a discretionary ACL (DACL), the SMB user is granted or denied access based upon this DACL.

The NTFS discretionary access permissions (described in the DACL) for files and folders on the share can be managed using the Windows Explorer on the client, by selecting the Security tab of the properties of the file or folder, see Figure 8.

Figure 8. Folder properties


Best practice When creating ACLs for SMB, it is very rare to have deny ACEs, but if required they should be first (before any allow ACE). See the example ACL below where ACE1 is the deny ACE and is listed before any of the allow ACEs.

Figure 9. Example ACL

NFSv4 ACLs NFSv4 introduced a new ACL model that fully supports the interoperability that NFSv4 offers between Linux/UNIX and non-Linux/UNIX clients. The new ACL implementation, as defined in the NFSv4 specification, provides finer granularity than typical POSIX read/write/execute permissions and much richer semantics that are similar to Windows style ACLs. The main difference between the NFS4 ACLs and the POSIX ACLs is the higher fidelity bits in the permission mask (17 permission bits, instead of the three used by POSIX – rwx).

The Converged ACL (using UPNs instead of SIDs/UIDs/GIDs) is stored on disk in the extended file attributes (xattr) of the file system. How to manage these depends on the security mode selected:

• In all modes, the HPE 3PAR CLI can be used to manage the ACL of only the share folder.

• In the NTFS security mode, only Windows clients can modify Windows ACLs, which FP converts to the Converged ACL.

• In the Legacy security mode, POSIX clients modify permissions based on the tools available per protocol: e.g., NFS3 clients can use chmod, setfacl; nfs4 clients can use chmod or nfs4_setfacl, HTTP and FTP only use change mode bits (chmod), and FP converts those to the Converged ACL.

When using NFSv4 client, or the nfs-acl tools when using versions prior to NFSv4. There is a difference how NFS clients handle ACLs, depending on the version of the client. The NFSv3 client only understands POSIX ACLs format over the wire, but not NFSv4 ACLs format.

Example of an NFSv4 ACL:

A:fd:OWNER@:rwaDdxtTnNcCoy

A:fdg:GROUP@:rwaDdxtTnNcCoy

A:fdg:domain users @ 2008AD.LAB:rxtncy

Example of a POSIX ACL:

# getfacl bothwrite

# file: bothwrite

# owner: root

# group: Administrators user::rwx

group::rwx other::---


Converged ACL HPE 3PAR File Persona uses the advanced HPE Adaptive File System that is designed for storing the converged ACLs on the disk in the NFSv4.1 ACL format for all files and directories and converts the ACLs to each protocol specific ACL for SMB, NFS, or HTTP clients, as described in Table 2 Converged ACLs. The Adaptive File System also performs the name resolution for the user name from the protocol-specific user name format to userPrincipleName (UPN) format to store on the disk.

Table 3. Converged ACLs

Converged ACL stack SMB NFSv3 NFSv4 Object Access API FTP

ACLs enforcer File Persona service FPG (file system) FPG (file system) FPG (file system) FPG (file system)

ACLs enforced by File Persona NTFS ACLs POSIX ACLs POSIX ACLs POSIX ACLs POSIX ACLs

On-disk ACLs stored NFSv4.1 ACLs NFSv4.1 ACLs NFSv4.1 ACLs NFSv4.1 ACLs NFSv4.1 ACLs

Name resolution Domain\username user@domainname

UID/GID user@domainname

user@domainname user@domainname

Domain\username user@domainname

Domain\username user@domainname

Table 3 Mapping of Converged System ACL permissions to Windows and POSIX, shows how the respective permission or various clients map to the HPE 3PAR converged ACL.

Table 4. Mapping of Converged System ACL permissions to Windows and POSIX

Converged ACL (HPE 3PAR CLI and GUI) Windows ACLs POSIX ACLs (permission bits)

r ReadData/ListDirectories ReadData/List Folders r: ReadFile/ListDir

n ReadNamedAttributes ReadExtendedAttributes

x ExecuteFile/TraverseDirectory ExecuteFile/TraverseFolder x: ExecuteFile/TraverseDirectory

w WriteData/CreateFiles WriteData/CreateFiles

w: Write file object

(All 4 “waTN” required to have “w” for write on directory)

a AppendData/CreateDirectories AppendData/CreateFolders

T WriteAttributes WriteAttributes

N WriteNamedAttributes WriteExtendedAttributes

D DeleteChild (dirs only) DeleteSubfoldersAndFiles (All 5 “waTND” required to have “w” for write on directory)

o ChangeOwnership (of file/dir) TakeOwnership

Ignored

t ReadAttributes ReadAttributes

c ReadACLs ReadPermissions

C Write ACLs ChangePermissions

d Delete object Delete

Effective permissions to users The user’s effective permissions are a combination of the share permissions and the folder/file ACL where the most restrictive permission will prevail.

Some examples, if a user wants to read a file, the user must have at least read permissions on file share level, including at least traverse permissions in each of the directory components from the share root folder to the file object of interest, and an ACE in the ACL that grants the user read permissions to the specific file. For example if a user has the appropriate ACE to read files in a folder ACL, but does not have (at least) read permissions on the file share, the user will not be able to map the file share in the first place.

Another example, if a user has the appropriate ACE to read files in a folder ACL and the user has (at least) read permissions on the file share, but the IP address of the client is on the denied list, access will be denied.


Best practice After creating the file share, log on to the file share with one of the default users and add the administrative users to the file share. After this, one of the administrative users can be used to manage file-share access using the Windows Explorer at the Windows client (for the NTFS security mode), or from an NFS client (for the Legacy security mode).

Server Message Block (SMB) share management The share level permissions can be managed using the SSMC or the Microsoft Management Console (MMC), however note that MMC does not have the ability to create File Stores and therefore the Storage Administrator should manually create a File Store in the VFS before handing over to the Windows Administrator to create shares. If the File Store has not been created, the Windows Admin may create shares in the default File Store (.admin) in the VFS, which is not recommended.

Best practice It’s recommended to manage the file shares on File Persona from the SSMC interface for more flexibility and control.

It’s recommended for the storage administrator to manually create the File Stores before handing over to the Windows Administrator to avoid the file shares being created in the default File Store.

When creating an SMB file share from the SSMC, there are three sub sections: General, Share Path, and Additional Settings. From the General section, the share type must be selected as well as the name and array.

Figure 10. Create SMB file share: General section

In the Share Path section, the Virtual file server and File store have to be selected and subdirectory which will make the share path.

Figure 11. Create SMB file share: Share Path section


The Additional Settings section will allow to set client filters, share permissions, and others.

Figure 12. Create SMB file share: Additional Settings section

Best practice HPE recommends the storage administrator to manually create the File Store before handing over to the Windows administrator (using MMC) to avoid that file shares are being created in the default File Store.

Persistent Handles (PH) The SMB3 protocol introduces the Persistent Handles feature to support Continuous Availability (CA) for a share. A share is said to be CA, if a client is able to access data even when network disconnects happen or failovers occur. CA enhances the high availability (HA) features of the SMB protocol. All shares in HPE 3PAR File Persona using SMB are by default CA shares if they are created using the CLI or the StoreServ Management Console (SSMC.) Shares that are created using the Microsoft Management Console (MMC) should default to CA shares as well.

The Persistent Handles can be disabled on an SMB share in the SSMC when creating or editing the File Share, see Figure 12 Create SMB file share: Additional Settings section, or by using the CLI command setfshare smb –ca false <vfs> <sharename>.

When Persistent Handles are enabled the server will save specific metadata associated with the open handle for opens from SMB3 clients, which requested Persistent Handle behavior when they open files. After this, if a failover occurs, it does not impact the applications accessing the open files or their content. The advantage of the PH feature is that a transient network failure or a server failure is not visible to the SMB clients enhancing end-user satisfaction. The SMB client application only may observe a small pause of I/O during a server failure but will be able to continue I/O using with the same handle. In the event that an SMB client gets disconnected, it can reconnect within five minutes with the same file handle and can resume operation from the same state.

When File Persona grants a persistent handle, it stores the metadata related to the persistent open into its memory as the metadata store called a Persistent Handle Store (PHS). When the SMB client gets disconnected the metadata remain in the PHS for a stipulated time (the time that is negotiated with client during persistent handle create). Typically, it is a five-minute timeout; however it is negotiable by client/server, as per the SMB3 specifications. Usually what happens is that the server negotiates a five-minute timeout, and the client simply accepts that.


When the disconnected client tries to reconnect, the Virtual File Server verifies the parameters with its persistent handle store and, if successful, returns success to the reconnect request. In that case, the SMB client can resume its operation.

When an SMB client has a persistent handle for a file and gets disconnected other SMB clients trying to open the same file, will be denied by the Virtual File Server. This is called “defending” the disconnected persistent handle. This is different from SMB2.1 durable handles, where other opens were allowed, and wiped out the resumable file state. That is why, unlike the Durable Handle feature (supported in SMB2 and SMB2.1), Persistent Handle is resilient to Virtual File Server failure and have strong guarantees on handle availability and I/O time out during a failover. This enhances data integrity on Group Shares where multiple users are accessing the same files.

Best practice Keep the default value for Persistent Handles (enabled) feature to support Continuous Availability (CA) for a share enhancing the high availability (HA) features of the SMB protocol.

File locking File locking is a mechanism that restricts access to a computer file by controlling how many users or processes can access it, and with what types of access, at any specific time. SMB uses two distinct mechanisms to manage access to shared files:

• Using share-access controls that allow applications to specify whole-file access for read, write, or delete

• Using byte-range locks (BRLs) to arbitrate read and write access to regions within a single file

HPE 3PAR File Persona supports cross-protocol file sharing, when using the NTFS security mode share mode locks taken by Windows clients are not only honored by other Windows clients but across all protocols. When an SMB client gets a BRL on a range, this BRL is visible to other protocols as an advisory POSIX byte range lock. Since it is an advisory lock and not a mandatory lock, other protocol attempts to acquire BRLs that conflict with existing SMB BRLs will fail, but other protocol read or write accesses to regions for which a BRL is held will not be blocked by the filesystem or the protocols.

Figure 13. File locking when using cross-protocol

Opportunistic locks Opportunistic lock or oplock is a file locking mechanism designed to improve performance by controlling caching of network files by the client that allows SMB clients to dynamically decide the client-side buffering strategy so the network traffic can be minimized to improve performance. In SMB2.1 and above, client oplock lease model allows more flexibility for controlling client caching using opportunistic locks. This feature brings performance improvement by reducing network bandwidth consumption, greater file server scalability, better response time when access the files over a network. The only disadvantage of the file level oplocks/leases is that if there are any changes in the files/folders on the file server, clients with the cached listing of that directory would not be aware of the changes until directory listing is refreshed locally on the client. In SMB3.0, the directory leasing feature improves this behavior further, by allowing the SMB client to cache the directory and file meta-data together in a consistent manner for longer duration. Clients are notified when directory information on the server changes and the data resynchronizes and updates the cache. This feature is designed to work with user home folders (read/write with no sharing) and published shares (read-only with sharing). This results in improved network performance and faster response time, however when using cross-protocol oplocks are not supported.


Best practice Oplocks and leases are enabled by default on File Persona. For best performance, keep oplocks and leases enabled if cross-protocol access is not required in your environment.

If your environment requires cross-protocol access, then oplocks and leases should be disabled, to provide consistency guarantees across multiple protocols. Verify enableoplock and enablesmbleases are set to false with setfs smb, or use SSMC (3.1 or later) where users can check or set SMB protocol settings in SSMC under File Persona, Edit Protocol Settings, SMB Settings.

SMB limits for File Persona For SMB file sharing, some restrictions apply when using cross-protocol. The following operations are only supported by SMB and must be disabled or avoided when using cross-protocol:

• SMB oplocks and leases must be disabled (enabled by default).

• Windows Alternate Data Streams (ADS) should be avoided in cross-protocol as SMB will use them however other protocols will not be aware of ADS, and if a non-SMB protocol renames a file can lose access to one, or more, Alternate Data Streams.

For the limits of the HPE 3PAR StoreServ or File Persona, please refer to the HPE 3PAR Support Matrix available at the Single Point of Connectivity Knowledge (SPOCK) website at hpe.com/storage/spock/. In the left pane navigate to “Other Hardware”, >>3PAR.

Best practice Keep the File Persona configuration within the limits specified in this document and in the HPE 3PAR Support Matrix to optimize File Persona and Block Persona performance.

Network File Services (NFS) share management The NFS share management can be done either via CLI or StoreServ Management Console (SSMC) for the following functions:

• Manage the NFS shares to create/update/delete/enumerate NFS shares using either the default share options or customized share options.

• Create a list of IP addresses, which should be either denied of allowed access.

• Manage the shares enumeration at the File Provisioning Group, Virtual File Server, or File Store level.

To be backwards compatible, the NFS share will have entries for NFSv3 and NFSv4 when the NFS share is created. This will be done automatically by the HPE 3PAR File Persona, which will bind the connecting clients to the correct export depending on the version of the client.

NFS servers uniquely identify each file using a file handle. When an NFS client performs an operation, it passes the file handle to the server, which decodes the file handle to determine what object the file handle refers to. The File Persona will handle File System Identifier (FSID) management by the automatic creation and assignment of random FSIDs unique within the node pair. To ensure the FSID is unique within the node pair the File Persona manages the FSIDs in a global cache. FSID collision will be automatically detected by the File Persona and updated accordingly in case a File System is moved to another node pair.

The create file share menu in the SSMC breaks up in three sections: General, Share Path, and Additional Settings. From the General section, the share type must be selected as well as the name and array.

https://www.hpe.com/storage/spock/


Figure 14. Create NFS file share: General section

In the Share Path section, the Virtual file server and File store have to be selected and subdirectory which will make the share path.

Figure 15. Create NFS file share: Share Path section

The Additional Settings section will allow to set client filters, share permissions, and others.

Figure 16. Create NFS file share: Additional Settings section

It is critical that the client mount is using the proper IP address for the VFS to avoid failures in case of deactivation of the containing FPG. To ensure the correct IP address is used by the NFS client, HPE recommends not to use the automount functionality for NFS clients.


Share configuration When a share is created, the base folder’s (or share root folder’s) ownership and permissions are specific to the security mode’s rules.

When the share is created with the Legacy security mode, the base folder will have the following attributes set: “root” as owner and “Administrators” as group with “770” as permissions, if the folder did not previously exist, or if it existed it was empty (0 non-hidden files).

With NTFS security mode, the default ownership and permissions when creating a file share are consistent: owner is root, and the permissions are inherited from the parent directory (e.g., the File Store directory) based on Windows inheritance rules. If the share root directory already existed, the ownership and permissions are maintained (not overwritten) when the share is created. The resulting POSIX ACL and mode bits are generated from converting the share folder’s ACL to POSIX ACL and UNIX mode bits.

The recommendation is to modify the permissions using the HPE 3PAR CLI setfhare, if it is desired:

• For Legacy security mode, use the –owner|-group|-chmod options (-acl is not recommended)

• For NTFS security mode use the –acl option (the –owner and –group are allowed but not recommended, -chmod is not allowed). In the NTFS security mode, the permissions at the share folder can also be modified from the Windows client after mapping the share as SYSTEM@NT_AUTHORITY or as a member of the Administrators@B-LOCAL_CLUSTER group. Modifying the permissions from a Windows client is the best practice to maintain 100% NTFS ACL semantics.

Note HPE 3PAR File Persona does not support using the automount functionality on the NFS client.

Before NFS users can access cross-protocol share, the following settings for File Store must be set, otherwise users will see benign errors while creating directories: setfstore secop_errsuppress true <vfs> <fstore>. By default, error suppression is disabled (check with showfstore).

Best practice It is recommended to only use the information displayed by SSMC for listing and configuring NFS mounts, and NOT the output of the Linux showmount –e command as the Linux showmount command is only designed for NFSv3 (not NFSv4) and the SSMC will show a single (NFSv3 and v4 symmetric) export path.

Do not use the automount functionality for NFS clients as that is not support by File Persona.

Client access Mount the share from the client using the proper assigned VFS IP address (exporting the NFS share) with either NFSv4 or NFSv3 clients.

Managing NFS permissions Only in the Legacy mode permissions can be managed (ownership, mode bits and ACLs) of file objects in share from NFS clients. In the NTFS security mode, users are not allowed to set permissions from NFS or any POSIX protocol client. However independent of the security mode, NFS clients can “view” permissions. The ACLs are stored on disk in the extended file attributes (xattr) of the file system and can be managed (or viewed-only when NTFS security mode is used) using the “nfsv4- acl-tools”, when using NFSv4 client, or the “nfs-acl-tools” when using NFS versions prior to NFSv4. There is a difference how NFS clients handle ACLs, depending on the version of the client. The NFSv3 client understands POSIX ACLs format and NFSv4 clients can understand both POSIX and NFSv4 ACLs format.

When the NFS client is used on a Windows platform the NFS permission on a file or folder can be configured using Windows explorer (again, only available when the Legacy security mode has been used):

1. Open Windows Explorer: click Start, point to Programs or All Programs, point to Accessories, and then click Windows Explorer.

2. Right-click the name of the file or directory.

3. Click Properties, and then click the NFS Attributes tab.

4. In File attributes (mode), select or clear the check boxes corresponding to the mode bits that you want to use, click Apply, and then click OK. To close the dialog box without making any changes, click Cancel.


File locking NFSv3 is a stateless protocol, whereas NFSv4 introduces “state” to notify an NFSv4 server of its intentions on a file: locking, reading, writing, and so on. An NFSv4 server can return information to a client about what other clients have intentions on a file to allow a client to cache file data more aggressively via delegation.

NFS limits for File Persona For NFS file sharing the limits listed in the support matrix for HPE 3PAR StoreServ or File Persona should be taken into consideration, please refer to the HPE 3PAR Support Matrix available at the Single Point of Connectivity Knowledge (SPOCK) website at hpe.com/storage/spock/. In the left pane navigate to “Other Hardware”, >>3PAR.

Best practice Keep the File Persona configuration within the limits specified in this document and in the HPE 3PAR Support Matrix to optimize File Persona and Block Persona performance.

Object Access API share management Web services can be considered as “RESTful” if they conform to the constraints described in the architectural constraints of “Representational state transfer” (REST). It changes the way programs interact with storage, complex file system semantics are compressed into a small number of commands. The Object Access API is a simple way for applications to interact with the storage where, unlike SMB/NFS, HTTP access is available from nearly every device. This enables developers and customers to integrate direct file access into their applications. The Object Access API of HPE 3PAR File Persona is a rich set of file system semantics enabling RESTful applications to access files and folders on the File Share directly using REST API.

The File Persona supports the following Object Access API operations:

• Create/replace a file

• Download file

• Copy file

• Delete file

• Retrieve file information

• Create directory

• Retrieve directory content

• Delete directory

• Get directory details

• Change owner

• Change group

• Set extended attributes

• Get extended attributes

• Remove extended attributes

• Commit data to disk

• Rename file

• Partial File Access (Supports byte range operations)

For Object Access API to be able to access files and folders on its file share a registered user (either in Local Users & Groups, Active Directory or LDAP) is required. When successfully authenticated file/directory permissions will be validated using the POSIX ACL.

https://www.hpe.com/storage/spock/


File Persona will convert the Converged ACL stored on disk to a POSIX ACL, validate permissions and grant access when successful. When permissions are changed, using one of the POSIX commands (Change group [chgrp], change owner [chown], Change mode [chmod]), File Persona will convert the Converged ACL stored on disk to a POSIX ACL and validate permissions and, if permissions allow, make the changes and convert back to Converged ACL, which will be stored on disk.

Object Access API file shares in File Persona can be managed using either the HPE 3PAR StoreServ CLI or the SSMC.

The create file share menu in the SSMC breaks up in three sections: General, Share Path, and Additional Settings. From the General section, the share type must be selected as well as the name and array. In the Share Path section, the Virtual file server and File store must be selected and subdirectory which will make the share path. In the Additional Settings, there is the option to enable (default is disabled) SSL support and the URL can be specified.

Figure 17. Create file share: Object Access

File locking Since HTTP is a stateless protocol it does not support file locking, like Byte Range Locks or Pessimistic concurrency control—this implies that the service locks the resource so that a client cannot updated it. While the resource is locked, no other client can modify it. However, to support concurrent updates to files it does support optimistic concurrency control—this implies that a client first obtains a token for the update operation. Once the token is received, it allows the client to perform the update. However, the changes will only apply if the token is still valid.

The Object Access API does not support file locking (this is true for all Object Access APIs, like AWS S3, Swift, etc.). When the user is editing a document using the Object Access API the document will be edited locally (on the client where the application is running). When the user has finished editing the document and wants to save the updates the document will be posted to the Virtual File Server using the Object Access (REST) protocol. File Persona will handle that post request as follows:

• When the user (or application) is posting the document, the VFS will place the incoming bytes in a temporary file and once the POST has finished, the VFS will rename the temporary file into its final object path.

• This mechanism protects the files from corruption, since the POSIX rename operation is atomic. However, if two users start editing the same document at the same time then the latest updates from the last user will be posted in the final document.


File Transfer Protocol (FTP) share management FTP shares are accessible through (S)FTP protocol clients through the IP address specified during the creation of FTP share configuration or any of the IP address, which have been added later. When creating the FTP share, only one VFS IP address can be used, later other VFS IP address(es) can be added. The FTP share will not be accessible from IP addresses outside a VFS subnet, for security reasons and to provide consistent failover. The FTP share does support both NTFS and Legacy security modes, however anonymous FTP is only supported when using the Legacy security mode.

Figure 18. FTP shares

The FTP share can be managed using the SSMC or HPE 3PAR CLI using the createfshare ftp, setfshare ftp, showfshare ftp and removefshare.

Figure 19. Create FTP share


Best practice FTP shares are configured with VFS IP addresses. The maximum number of FTP shares is limited to the number of IP’s configured for that VFS provided each share is having only one IP.

Troubleshooting Overview Creating an “InSplore” is always a good start to collect as much (recent) information as possible. To create an InSplore, start a web browser session to the Service Processor and log in using “3parcust”, click the “Support” bezel on the left. Then, from the right frame, under the InServs section, click “InSplore”. This will launch an InSplore with a pop-up window displaying the status. The InSplore will continue to run as a background process. At the end of this process, the InSplore will be collected on the SP. If the SP is configured to send outbound traffic to HPE 3PAR Central, the InSplore will to be sent to HPE without further user intervention. If the SP is not configured to send outbound traffic, download the file locally.

The shared File Shares have health monitoring, which has two states—“Good” and “Failed”. The “Good” state means that when queried, the Platform Management Layer (PML) is able to contact each node. “Failed” means that when queried, the PML was unable to contact all nodes.

When viewing or setting permissions on files and directories it is important to know how permissions will be mapped to the File Persona converged ACL, see Table 3 Mapping of Converged System ACL permissions to Windows and POSIX for more details.

NFS troubleshooting Use the CLI command below to see the statistics of the NFS file share protocol. Check for the number of concurrent connections, etc., to verify they are within the support limits.

statfs – nfs [-iter <number>] [-d <secs>] [-node <nodeid>[,<nodeid>]...] [-verbose]

SMB troubleshooting From a Windows client mount the share and launch PowerShell, go to the share directory (e.g., Y:) and run Get-Acl | Format-List

Path : Microsoft.PowerShell.Core\FileSystem::Y:\ Owner : BUILTIN\Administrators

Group : G:S-1-5-21-2330347856-3681406247-438683984-513

Access : Everyone Allow ReadAndExecute, Synchronize CREATOR OWNER Allow FullControl

S-1-5-21-2943099029-2375420575-3763763779-513 Allow FullControl

Audit :

Sddl : O:BAG:S-1-5-21-2330347856-3681406247-438683984-513D:PAI (A;OICI;0x1200a9;;;WD)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;S-1-5-21-2943099029- 2375420575-3763763779-513)

Use the CLI command statfs – smb [-iter <number>] [-d <secs>] [-node <nodeid>[,<nodeid>]...] [-verbose] to see the statistics of the SMB file share protocol.

Object Access API troubleshooting The curl tool with –v option can be used to get verbose information from request and response, which can be analyzed to see what the issue could be. Errors are returned as appropriate HTTP errors codes with accompanying JSON error information in the response.

Table 5. HTTP error codes (not an exhaustive list)

HTTP status code Reason

200 or 204 When operation was successful

400 Invalid Range header

404 File not found

416 Request Range not satisfiable (end byte being lower than the start byte)


Appendix Other tools to manage permissions of files and folders on file shares hosted by File Persona.

SMB MMC (Microsoft Management Console), Icacls.exe and PowerShell get/set-acl are all supported methods to manage the file and folder permissions on an SMB share hosted by File Persona.

Icacls.exe Displays or modifies discretionary access control lists (DACLs) on specified files, and applies stored DACLs to files in specified directories. Icacls is a Windows built-in CLI command.

C:\Windows\system32>icacls \\192.168.47.207\DomainUsers\CreatedUsingSMB

\\192.168.47.207\DomainUsers\CreatedUsing

SMB 3PAREBC\UnixUsers:(OI)(CI)(RX)

CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Everyone:(I)(OI)(CI)(F)

NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)

BUILTIN\Administrators:(I)(OI)(CI)(F)

Successfully processed 1 file; failed processing 0 file. For more information on icacls, type icacls in a Windows command prompt or read the Microsoft TechNet article at technet.microsoft.com/en-us/library/cc753525.aspx.

Get/Set-Acl Another option to manage files and folder permissions on SMB shares is to user the PowerShell cmdlets Get-Acl and Set-Acl see Microsoft TechNet at technet.microsoft.com/en-us/library/ee176838.aspx.

PS C:\ > get-acl \\192.168.47.207\DomainUsers\CreatedUsingSMB|format-list Path : Microsoft.PowerShell.Core\FileSystem::\\192.168.47.207\DomainUsers\ CreatedUsingSMB Owner : 3PAREBC\Marks Group : 3PAREBC\UnixUsers Access : 3PAREBC\UnixUsers Allow ReadAndExecute, Synchronize CREATOR OWNER Allow FullControl 3PAREBC\marks Allow FullControl Everyone Allow FullControl NT AUTHORITY\SYSTEM Allow FullControl BUILTIN\Administrators Allow FullControl

Audit:

Sddl: O:S-1-5-21-1119649910-1116511031-265831756-1173G:S-1-5-21-1119649910- 1116511031-265831756-1176D:

(A;OICI;0x1200a9;;;S-1-5-21-1119649910-1116511031-265831756-1176) (A;OICIIOID;FA;;;CO)(A;ID;FA;;;S-1-5-21-1119649910-1116511031-265831756- 1173)(A;OICIID;FA;;;WD)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)

NFS To manage files and folders permission use the NFS client tools, nfsv4_getfacl (NFSv4) or getfacl (NFSv3).

$ getfacl smbw # file: smbw # owner: root # group: 4294967294

user::rwx group::rwx other::r-x

Use the CLI command statfs –nfs [-iter <number>] [-d <secs>] [-node <nodeid>[,<nodeid>]...] [-verbose] to see the statistics of the NFS file share protocol.

https://technet.microsoft.com/en-us/library/cc753525.aspx

https://technet.microsoft.com/en-us/library/ee176838.aspx


Sign up for updates

© Copyright 2015, 2017 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. UNIX is a registered trademark of The Open Group. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. All other third-party trademark(s) is/are property of their respective owner(s).

4AA6-0699ENW, August 2017, Rev. 1

Revision history Table 6. Document revision

Document revision Updated for HPE 3PAR OS version

August 2015 3.2.1 MU2

August 2017, Rev. 1 3.3.1 P08

Related documentation HPE 3PAR StoreServ Storage Best Practice Guide

HPE 3PAR File Persona with HPE Recovery Manager Central

Corporate and Group Shares best practices guide for HPE 3PAR File Persona

Protecting HPE 3PAR File Persona data

HPE 3PAR Object Access API Reference

For identifying storage system configuration specifications and compatibility information, go to the SPOCK website at h20272.www2.hpe.com/spock/.

Learn more at hpe.com/storage/3parfilepersona

http://www.hpe.com/info/getupdated

https://www.hpe.com/global/hpechat/index.html?jumpid=Collaterals_4AA6-0699ENW

http://www.facebook.com/sharer.php?u=http://www.hpe.com/h20195/V2/GetDocument.aspx?docname=4AA6-0699ENW

http://twitter.com/home/?status=File%20sharing%20best%20practices%20guide+@+https://www.hpe.com/h20195/V2/GetDocument.aspx?docname=4AA6-0699ENW

http://www.linkedin.com/shareArticle?mini=true&ro=true&url=https://www.hpe.com/h20195/V2/GetDocument.aspx?docname=4AA6-0699ENW&title=File%20sharing%20best%20practices%20guide+&armin=armin

https://www.hpe.com/h20195/v2/Getdocument.aspx?docname=4AA4-4524ENW




http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04532652

https://h20272.www2.hpe.com/spock/

http://hpe.com/storage/3parfilepersona

Documents

File sharing best practices guide - Hewlett Packard Enterprise · File sharing best practices guide . HPE 3PAR File Persona . ... (S MB, NFS, FTP, and Object Access API), where SMB