No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Basic Storage Service Configuration Guide for File

OceanStor V3 Series V300R006

This document is applicable to OceanStor 2200 V3, 2600 V3, 5300 V3, 5500 V3, 5600 V3, 5800 V3, 6800 V3, 18500 V3, and 18800 V3. It describes the basic storage services and explains how to configure and manage them.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Cross-Protocol Share Access

Cross-Protocol Share Access

A storage system allows NFS and CIFS shares to be configured for the same file system concurrently. This section describes how a storage system uses the user mapping function to allow users to access shared files across protocols (CIFS-NFS) used by clients on different platforms and implement precise permission control.

Overview

This section introduces the user mapping mechanism used during cross-protocol (CIFS-NFS) share access.

CIFS-NFS Cross-Protocol Share Access

A storage system allows users to share a file system or quota tree using NFS and CIFS at the same time. Different clients can access a file system or quota tree simultaneously. Windows, Linux, and UNIX adopt different mechanisms to authenticate users and control access. The storage system manages user mapping and permission control of different operating systems in a unified manner, protecting the security of CIFS-NFS cross-protocol access.

  • If a CIFS user attempts to access a file or directory, the storage system authenticates local or AD domain users first. If the UNIX permission (UNIX Mode bits, or NFSv4 ACL) has been configured for the file or directory, the CIFS user is mapped as an NFS user based on preset user mapping rules during authentication. Then the storage system performs UNIX permission authentication for the user.
  • If an NFS user attempts to access a file or directory with NT ACLs, the NFS user is mapped as a CIFS user based on the preset mapping rules. Then the storage system performs NT ACL permission authentication for the user.
CIFS-NFS Cross-Protocol Access Permissions

If permission types of a file or directory and a client that attempts to access the file or directory do not match, CIFS-NFS cross-protocol access is required and you must map the permission of the file or directory so that it can be displayed by the client.

  • NFS client accessing a file or directory with the NTFS permission

    When an NFS client checks the NTFS permission that a file or directory has, the client can obtain the UNIX permission mapped from an NT ACL. The NFS client displays as many permissions as possible but the actual permissions are determined by the NT ACL. For example, the NFS client shows that all users have read, write, and execute permissions, but one of the users may only have the write permission.

  • CIFS client accessing a file or directory with the UNIX permission

    When a CIFS client checks the UNIX permission that a file or directory has, the UNIX permission is mapped into three ACEs for the CIFS client. The three ACEs are for the owner, owner primary group, and everyone of the file or directory respectively. The NT ACL is displayed only but not used to control actual operation permissions.

Table 3-58 shows how permissions are converted among UNIX Mode bits, NFSv4 ACLs, and NT ACLs.

Table 3-58 Permission conversion among UNIX Mode bits, NFSv4 ACLs, and NT ACLs

File Permission

Permission Conversion

A file or directory only has valid UNIX Mode bits.

  • If an NFS or CIFS client sends a request to read an ACL, one ACL is mapped based on UNIX Mode bits.
  • If an NFSv4 client sends a request to set an ACL, an NFSv4 ACL takes effect and UNIX Mode bits are mapped based on the NFSv4 ACL.
  • If a CIFS client sends a request to set an ACL, an NT ACL takes effect and UNIX Mode bits with the maximum permissions are mapped based on the NT ACL.

A file or directory has a valid NFSv4 ACL or NT ACL.

  • NFS clients use the chmod command to change permissions. The NFSv4 ACL or NT ACL is abandoned and UNIX Mode bits take effect.
  • NFS clients use the chmod command to add or remove SUID/SGID/STICKY. The NFSv4 ACL or NT ACL is abandoned and UNIX Mode bits take effect.

A file or directory has a valid NFSv4 ACL.

  • If an NFS client sends a request to read UNIX Mode bits, UNIX Mode bits (mapped based on the NFSv4 ACL) of the storage system are returned directly.
  • If a CIFS client sends a request to read an NT ACL, an NT ACL is mapped based on the NFSv4 ACL (an NT ACE corresponding to V4Domain\name is generated for each NFSv4 ACE). Due to the difference between ordering rules of the NFSv4 ACL and NT ACL, the CIFS client may display a message indicating that the order of the NT ACL mapped based on the NFSv4 ACLs is incorrect. Before setting an ACL on a CIFS client, delete all mapped NFSv4 ACLs. Otherwise, the setting will not take effect.
  • If a CIFS client sends a request to set an NT ACL, all ACEs that correspond to V4Domain and are mapped based on the NFSv4 ACL must be deleted on the CIFS client, and new NT ACEs must be added. Then, the NFSv4 ACL is abandoned and the NT ACL takes effect. UNIX Mode bits are mapped based on the NT ACL.

A file or directory has a valid NT ACL.

  • If an NFS client sends a request to read UNIX Mode bits, UNIX Mode bits (mapped based on the NT ACL) of the storage system are returned directly.
  • If an NFSv4 client sends a request to read an NFSv4 ACL, an NFSv4 ACL is mapped based on UNIX Mode bits of the storage system.
  • If the NFSv4 client sends a request to set an NFSv4 ACL, an NT ACL is discarded, an NFSv4 ACL takes effect, and UNIX Mode bits are mapped from the NFSv4 ACL.
CIFS-NFS Cross-Protocol User Mapping

Windows systems (CIFS) and Linux systems (NFS) use different mechanisms to identify and authenticate users:

  • Windows systems use security identifiers (SIDs) to identify users. SIDs apply to all users, user groups, services, and computers in the systems. CIFS supports NT ACLs for authentication.
  • Linux systems use user identities (UIDs) and one or more group identities (GIDs) to identify users. One user belongs to one user group at least. NFS supports diversified security control mechanisms such as UNIX Mode bits and NFSv4 ACL for authentication.

During CIFS-NFS cross-protocol share access, users using different protocols must be mapped based on user mapping rules for user authentication and precise permission control.

The timing of user mapping is as follows:

  • When a CIFS client accesses files or directories with the NFSv4 ACL or UNIX Mode bits permission, a user mapping occurs. A user will have both the permissions before and after user mapping.
  • When an NFS client accesses files or directories with the NT ACL permission, a user mapping occurs. A user will have both the permissions before and after user mapping.
  • Cross-protocol permission editing changes permission types. For example, users are mapped when an NFS client accesses a file or directory that has the NT ACL permission. If the NFS client runs the chmod command or sets the NFSv4 ACL to change the permission of the file or directory, users are not mapped when the NFS client accesses the file or directory after the change. That is, users' permissions remain unchanged.
NOTE:

It is not advised to edit permissions across protocols, avoiding permission type changes.

  • When a parent directory has inheritable NT ACL permission, files or directories created no matter on an NFS client or a CIFS client will have the NT ACL permission by default. In this case, if the NFS client accesses files or directories, a user mapping will always occur. That is, a user will have both the permissions before and after user mapping. When the parent directory does not have any inheritable NT ACL permission, files or directories created no matter on an NFS client or a CIFS client will have the UNIX Mode bits permission. In this case, if the NFS client accesses files or directories, no user mapping occurs. That is, the user's permission remains unchanged.
  • If mappings are changed on CIFS clients, the change takes effect after CIFS connections are disconnected and next re-authentication is performed.
  • User mappings on NFS clients are cached and expire after four hours by default. New user mappings and user information changes take effect after the cached data expires.

User mapping rules specify the mappings among different user accounts. They can be saved in a local database or managed in an AD domain in a centralized manner. A user mapping rule includes the mapping type, source user, mapped user, and mapping priority. If a user matches multiple mapping rules, it is mapped based on the rule with a higher priority. If the rules have the same priority, the user is mapped based on the rule that is configured the earliest.

The following describes how local user mapping is performed:

  • NFS-CIFS user mapping: An NFS user is authenticated by UID on the service end. When a user mapping occurs, the user name to which the UID corresponds will be queried in the sequence of the local host, LDAP domain, and NIS domain. Based on the queried user name and the local mapping, the user name, SID, and owning group of the mapped user will be queried.
  • CIFS-NFS user mapping: A CIFS user is authenticated by SID on the service end. When a user mapping occurs, the mapped user will be queried based on the user name to which the SID corresponds and the local mapping. Then the SID to which the mapped user name corresponds and its owning group will be queried in the sequence of the local host, LDAP domain, and NIS domain.
NOTE:

It is not advised to configure the same UID or user name in the local host, LDAP domain, or NIS domain. If the same UID or user name exists, the user mapping results will not be the expected results.

After user mapping, on an NFS client, the owner information of files or directories owned by CIFS users (the files or directories that are created by CIFS users or the owner information of the files or directories are changed to CIFS users) is the information of the NFS users mapped from CIFS users. If no mapping rules have been configured for CIFS users, the owner information of the files or directories is about the IDs (calculated using IDMAP, a hash algorithm) of the CIFS users. If the client is an NFSv4 client, the owner information is displayed as nobody.

After user mapping, on a CIFS client, the owner information of the files or directories owned by NFS users (the files or directories that are created by NFS users or the owner information of the files or directories are changed to NFS users) is about NFS user names:

  • If NFS users are NIS domain users, the owner information is displayed as NIS_DOMAIN\user name.
  • If NFS users are LDAP domain users, the owner information is displayed as LDAP_DOMAIN\user name.
NOTE:

When CIFS users are mapped to NFS users, quota statistics will be collected for the NFS users or owning user group.

Managing User Mappings Across Protocols (CIFS-NFS)

Managing user mappings across protocols (CIFS-NFS) includes configuring the mapping parameters and creating a user mapping.

Configuring Mapping Parameters

You can create user mappings in both the local storage system and the external IDMU domain to access shares across different systems. The following introduces how to set the mapping mode as well as timeout duration of the IDMU query, and search for the domain name.

Context

If you only use IDMU user mappings, you do not need to configure user mappings in the local storage system.

Procedure
  1. Log in to DeviceManager.
  2. Choose Provisioning > User Authentication > User Mapping.
  3. Click Set Mapping Parameters.
  4. Set the mapping parameters.

    Table 3-59 describes the mapping parameters.
    Table 3-59 Mapping parameters

    Parameter Name

    Description

    Value

    Mapping Mode

    A global parameter of user mappings, including:

    • Not support user mapping: The system does not support user mappings.
    • Support only user mapping in the current system: The system only supports user mappings created locally.
    • Support only user mapping in IDMU: The system only supports user mappings in the IDMU domain.
    • Preferentially support user mapping in IDMU: When user mappings of a specific original user exist both in the system and the IDMU domain, the system preferentially uses the mapping in the IDMU domain.
    • Preferentially support user mapping in the current system: When user mappings of a specific original user exist both in the local system and the IDMU domain, the mappings in the current system are used preferentially.

    [Example]

    Support only user mapping in IDMU

    NOTE:

    GUIs may vary with product versions and models. The actual GUIs prevail.

    For V300R006C30 and earlier versions, the values of Mapping Mode are:

    • User mapping not supported
    • User mapping supported (Mapping rules set in local)
    • User mapping supported (Mapping rules set in IDMU)
    • User mapping supported (Mapping rules set in IDMU and local, IDMU preferentially)
    • User mapping supported (Mapping rules set in local and IDMU, local preferentially)

    IDMU Search Timeout Duration (s)

    Timeout duration for the system to search for specific user mappings in the IDMU domain.

    [Value range]

    5 to 120

    [Default value]

    15

    IDMU Search DN

    Benchmark directory where the system searches for specific user mappings in the IDMU domain. The benchmark directory stores information of user mappings.

    [Value range]

    The directory can be left blank or contain up to 255 characters.

    [Default value]

    None

    [Example]

    DC=auth2kh8,DC=com when the domain name is auth2k8.com.

  5. Click OK.

    The Success dialog box is displayed.

  6. Click OK.
Creating a Local System User Mapping

This operation enables the system to map a source user to a target user based on a mapping relationship for accessing shares across protocols.

Procedure
  1. Log in to DeviceManager.
  2. Choose Provisioning > User Authentication > User Mapping.
  3. Click Create.

    The Create User Mapping dialog box is displayed.

  4. Set the related parameters of the user mapping.

    Table 3-60 explains the related parameters.
    Table 3-60 User mapping parameters

    Parameter Name

    Description

    Value

    Mapping Type

    A user mapping type related to the operating system, including:

    • Windows to Unix: When accessing UNIX shares using Windows, a Windows user has all the permissions granted to the target user.
    • Unix to Windows: When accessing Windows shares using UNIX, a UNIX user has all the permissions granted to the target user.

    [Example]

    Windows to Unix

    Source User

    Source user in a mapping.

    [Example]

    sourceuser

    Target User

    Target user in a mapping.

    [Example]

    targetuser

  5. Click Add and set the Priority.

    NOTE:

    A smaller number indicates a higher priority. When multiple mappings share the same source user, the system uses the mapping with the highest priority.

  6. Optional: Click Test to check whether the target user exists.

    NOTE:

    Click Remove to delete the user mapping.

  7. Click OK.
  8. Click Close.
Example

  • User mapping rule 1: A UNIX user is mapped to a user of the same name in an AD domain (domain name: authtest). For example, UNIX user ABC is mapped to user ABC in the AD domain.
    • Source user: *
    • Target user: authtest\\1
    • Mapping type: Unix to Windows
    • Priority: 10 (default)
  • User mapping rule 2: A user in the AD domain (domain name: authtest) is mapped to a UNIX user of the same name.
    • Source user: authtest\*
    • Target user: \1
    • Mapping type: Windows to Unix
    • Priority: 10 (default)
  • User mapping rule 3: Windows user win_user01 is mapped to UNIX user ux_user01.
    • Source user: win_user01
    • Target user: ux_user01
    • Mapping type: Windows to Unix
    • Priority: 10 (default)

Accessing a CIFS File Across Protocols

This section describes how an NFS client accesses CIFS files and directories for which the NT ACL permission has been configured.

Prerequisites
  • A Linux client user has the same UID and GID as a local authentication user.

    You can query the local authentication user ID and ID of its owning primary group on the DeviceManager. On the Linux client, you can run the groupadd -g GID user group name command to create a user group, and then run the useradd -u UID -g GID user name command to create a user.

  • If an NFS client uses NFSv4, enable the NFSv4 service in the storage system and enter the domain name based on the specific environment:
    • In a non-domain or LDAP environment, enter the default domain name localdomain.
    • In an NIS environment, the entered information must be consistent with the domain in the /etc/idmapd.conf file on the Linux client that accesses shares. It is recommended that both the two be the domain name of the NIS domain.
  • Before you use an AD domain user to configure user mapping rules, the storage system (vStore) has been added to the AD domain.
Context

Before users can use an NFS client to access shared files and folders for which NT ACLs has been configured, the administrator must follow the process as shown in Figure 3-19 to configure related parameters.

Figure 3-19 Flowchart of configuring cross-protocol access of a CIFS file

Table 3-61 provides an example of data planning during the configuration.

Table 3-61 Example of data planning

Item

Planned Value

Description

File system

Name: share_dir

-

Local authentication user

local_user1

In this example, the default user group default_group is selected as the primary group.

NFS client user

linux_user1

The user must have the same UID and GID as the local authentication user.

NFS share

  • Type of the client: host
  • Name or IP address: 10.68.0.10
  • Permission: Read-write
  • Advanced: The default settings are used.

In this example, the Read-write permission for the NFS share is added to the client. In Advanced, default settings are used.

CIFS share

  • Share Name: share_dir_cifs
  • Oplock: Enable
  • Notify: Enable
  • User/User Group: local authentication user local_user1
  • Permission Level: Full control

In this example, the Full control permission for the CIFS share is added to local authentication user local_user1.

Mapping Mode

Local system user mappings are supported preferentially.

-

User mapping rule

  • Mapping Type: Unix to Windows
  • Source User: linux_user1
  • Target User: local_user1
  • Priority: 10

In this example, a Unix to Windows mapping rule is created. The source user is local authentication user linux_user1, whereas the target user is local authentication user local_user1. The priority of the mapping rule is set to 10.

Procedure
  1. Log in to DeviceManager.
  2. Create a file system.

    1. Choose Provisioning > File System.
    2. Create a file system named share_dir as planned.

  3. Create a local authentication user and record its ID and the ID of its owning primary group.

    1. Choose Provisioning > User Authentication > Local Authentication User.
    2. Click Create and create local authentication user local_user1 as planned.
    3. Select local_user1 and click Properties. Then record the user ID.
      Figure 3-20 Recording the ID of the local authentication user

    4. Click the Local Authentication User Group tab, select default_group, and click Properties to record the ID of the owning primary group of the local authentication user.
    Figure 3-21 Recording the ID of the owning primary group of the local authentication user

  4. Create an NFS share and a CIFS share for the same file system.

    1. Choose Provisioning > Share.
    2. Create an NFS share and a CIFS share for the same file system based on parameters as planned.

  5. Configure user mapping parameters.

    1. Choose Provisioning > User Authentication > User Mapping.
    2. Click Set Mapping Parameters and set Mapping Mode to Local system user mappings are supported preferentially.
    Figure 3-22 Configuring user mapping parameters

  6. Configure user mapping rules.

    1. Choose Provisioning > User Authentication > User Mapping.
    2. Click Create and configure user mapping rules as planned.
    Figure 3-23 Configuring user mapping rules

  7. Use a Windows client to access shared directory share_dir and set permissions of files under the shared directory.

    1. Use a Windows client to access a CIFS share.
    2. Under the shared directory, create folder subdir1 and file file1.
    3. Add one ACE to subdir1 and file1.

      Right-click the file or folder and choose properties from the shortcut menu that is displayed. In the properties dialog box that is displayed, click the Security tab and add the write permission ACE to user local_user1.

  8. Use an NFS client to mount the share and access the share as local user linux_user1.

    1. Use an NFS client to mount the NFS share.
    2. Run the groupadd -g 100000 linux_group command to create a user group that has the same GID as the local authentication user group.
    3. Run the useradd -u 100001 -g 10000 linux_user1 command to create a user that has the same UID and GID as the local authentication user.
      NOTE:

      The UID and GID in the command are used as an example only. They vary with site conditions.

    4. Run the su - linux_user1 command to switch users.
    5. Write data to folder subdir1.

      If the data is written to the folder successfully, the Linux client has a write permission for the folder.

Accessing an NFS File Across Protocols

This section describes how a CIFS client accesses an NFS share for which the UNIX permission has been configured.

Prerequisites
  • The IDMU component has been installed on the AD domain server and the NIS has been enabled.
  • Configuring a storage system to add it to a NIS domain has been completed and the NIS server is the NIS service of the AD domain controller.
  • The user of the Linux client has the same UID and GID as the local authentication user.

    You can query the local authentication user ID and ID of its owning primary group on the DeviceManager. On the Linux client, you can run the groupadd -g GID user group name command to create a user group, and then run the useradd -u UID -g GID user name command to create a user.

  • If the NFS client uses NFSv4.0 protocol or NFSv4.1 protocol, enable the NFSv4.0 service or the NFSv4.1 service in the storage system and enter the domain name based on the specific environment:
    • In a non-domain or LDAP environment, enter the default domain name localdomain.
    • In an NIS environment, the entered information must be consistent with the domain in the /etc/idmapd.conf file on the Linux client that accesses shares. It is recommended that both the two be the domain name of the NIS domain.
Context

Before users can use a Windows client to access shared files and folders for which the UNIX permission has been configured, the administrator needs to follow the process as shown in Figure 3-24 to configure related parameters.

Figure 3-24 Flowchart of configuring cross-protocol access of an NFS file

Table 3-62 provides an example of data planning during the configuration.

Table 3-62 Example of data planning

Item

Planned Value

Description

File system

Name: share_dir2

-

Local authentication user

local_user2

In this example, the default user group default_group is selected as the primary group.

NFS client user

linux_user2

The user must have the same UID and GID as the local authentication user.

NFS share

  • Type of the client: host
  • Name or IP address: 10.68.0.10
  • Permission: Read-write
  • Advanced: The default settings are used.

In this example, the Read-write permission for the NFS share is added to the client. In Advanced, default settings are used.

CIFS share

  • Share Name: share_dir_cifs2
  • Oplock: Enabled
  • Notify: Enabled
  • User/User Group: local authentication user local_user2
  • Permission Level: Full control

In this example, the Full control permission for the CIFS share is added to local authentication user local_user2.

Mapping Mode

Local system user mappings are supported preferentially.

-

User mapping rule

  • Mapping Type: Windows to Unix
  • Source User: local_user2
  • Target User: linux_user2
  • Priority: 10

In this example, a Windows to Unix mapping rule is created. The source user is local authentication user local_user2, whereas the target user is local authentication user linux_user2. The priority of the mapping rule is set to 10.

Windows operating systems do not allow a file name to contain special characters. Therefore, it is recommended that the file name and directory name of an NFS share do not contain special characters including \:*/?"<>|, and the file name and directory name do not end with a period (.) or a space. Otherwise, the storage system converts the file name and directory name to short names (for example, ~PY203).

Procedure
  1. Log in to DeviceManager.
  2. Create a file system.

    1. Choose Provisioning > File System.
    2. Create a file system named share_dir2 as planned.

  3. Create a local authentication user and record its ID and the ID of its owning primary group.

    1. Choose Provisioning > User Authentication > Local Authentication User.
    2. Click Create and create local authentication user local_user2 as planned.
    3. Select local_user2 and click Properties. Then record the user ID.
      Figure 3-25 Recording the ID of the local authentication user

    4. Click the Local Authentication User Group tab, select default_group, and click Properties to record the ID of the owning primary group of the local authentication user.
    Figure 3-26 Recording the ID of the owning primary group of the local authentication user

  4. Create an NFS share and a CIFS share for the same file system.

    1. Choose Provisioning > Share.
    2. Create an NFS share and a CIFS share for the same file system based on parameters as planned.

  5. Configure user mapping parameters.

    1. Choose Provisioning > User Authentication > User Mapping.
    2. Click Set Mapping Parameters and set Mapping Mode to Local system user mappings are supported preferentially.
    Figure 3-27 Configuring user mapping parameters

  6. Configure user mapping rules.

    1. Choose Provisioning > User Authentication > User Mapping.
    2. Click Create and configure user mapping rules as planned.
    Figure 3-28 Configuring user mapping rules

  7. Use an NFS client to mount the share and set permissions of files under the shared directory.

    1. Use an NFS client to mount the NFS share.
    2. Run the groupadd -g 100000 linux_group command to create a user group that has the same GID as the local authentication user group.
    3. Run the useradd -u 100002 -g 10000 linux_user2 command to create a user that has the same UID and GID as the local authentication user.
      NOTE:

      The UID and GID in the command are used as an example only. They vary with site conditions.

    4. Run the su - linux_user2 command to switch users.
    5. In the shared path, create a file hard.txt and run the ln command to point hard link hard_file to the file respectively.

  8. Use a Windows client to access the shared directory, and open, read data from, write data to, close, delete, and rename files under the shared directory.

    1. On the Windows client, use local_user2 to access shared directory share_dir2.
    2. Open, read data from, write data to, close, delete, and rename files under the shared directory.

      All operations on the folder and files are successful.

Translation
Download
Updated: 2019-07-12

Document ID: EDOC1000138856

Views: 62353

Downloads: 830

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next