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 Guide for File 16

OceanStor 5300 V3, 5500 V3, 5600 V3, 5800 V3, and 6800 V3 Storage System V300R003

"This document describes the basic storage services and explains how to configure and managebasic storage services."
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

The OceanStor 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 allows NFS sharing and CIFS sharing to be configured for the same file system concurrently. This chapter describes how the OceanStor 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 uses the user mapping function to allow users to access shared files across protocols (CIFS-NFS) used by clients on different platforms and obtain precise permission control. This function is only supported in V300R003C10 and V300R003C20.

Overview

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

CIFS-NFS Cross-Protocol Share Access

The 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 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. Since Windows, Linux, and UNIX adopt different mechanisms to authenticate users and control access, the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 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 on the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3, the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 authenticates local or AD domain users in the first place. If the UNIX permission (UNIX Mode bits, or NFSv4 ACL) has been configured for the file or directory to be accessed, the CIFS user is mapped as an NFS user based on preset user mapping rules during authentication. Then the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 performs UNIX permission authentication for the user.
  • If an NFS user attempts to access a file or directory that has NT ACL on the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3, the NFS user is mapped as a CIFS user based on the preset mapping rules. Then the 5300 V3/5500 V3/5600 V3/5800 V3/6800 V3 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 mismatch, CIFS-NFS cross-protocol access is required. You need to 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-41 shows how permissions convert among UNIX Mode bits, NFSv4 ACL, and NT ACL.

Table 3-41  Permission conversion among UNIX Mode bits, NFSv4 ACL, and NT ACL

File Permission

Permission Conversion

The file or directory only has valid UNIX Mode bits.

  • One ACL is mapped based on UNIX Mode bits when an NFS or CIFS client sends a request to read an ACL.
  • 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.

The 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.

The 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 UNIX Mode bits of the storage system.
  • If a CIFS client sends a request to set an NT ACL, the NFSv4 ACL is abandoned and the NT ACL takes effect. UNIX Mode bits are mapped based on the NT ACL.

The 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. Regarding authentication, CIFS supports NT ACLs.
  • 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. Regarding authentication, NFS supports diversified security control mechanisms such as UNIX Mode bits and NFSv4 ACL.

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. The user will have both the permissions before and after the user is mapped.
  • When an NFS client accesses files or directories with the NT ACL permission, a user mapping occurs. The user will have both the permissions before and after the user is mapped.
  • 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:
    You are advised not to edit permissions across protocols, avoiding permission type changes.
  • When the parent directory has the inheritable NT ACL permission, the 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, the user will have both the permissions before and after the user is mapped. When the parent directory does not have the inheritable NT ACL permission, the 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. The user mapping rules can be saved in a local database or managed in the AD domain in a centralized manner. A user mapping rule includes the mapping type, original 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.

A user mapping process is as follows: (Local mapping of a storage system is used as an example.)
  • 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 the 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 UID to which the mapped user name corresponds and its owing group will be queried in the sequence of the local host, LDAP domain, and NIS domain.
NOTE:
You are advised not to configure the same UIDs or user names in the local host, LDAP domain, or NIS domain. If the same UIDs or user names exist, the user mapping results will not be the expected results.

Managing User Mappings Across Protocols (CIFS-NFS)

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

Configuring Mapping Parameters

You can create user mappings in the local storage system as well as use user mapping in 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 by referring toTable 3-42.

    Table 3-42  Parameter description

    Parameter Name

    Description

    Value

    Mapping Mode

    A global parameter of user mappings, including:
    • User mapping not supported: The system does not support user mappings.
    • User mapping supported(rules set in local): The system only supports user mappings created locally.
    • User mapping supported(rules set in IDMU): The system only supports user mappings in the IDMU domain.
    • User mapping supported(rules set in IDMU or local. IDMU preferred): 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.
    • User mapping supported(rules set in IDMU or local. Local preferred): When user mappings of a specific original user exist both in the local system and the IDMU domain, the mappings in the local system are used preferentially.

    [Example]

    User mapping supported(Mapping rules set in IDMU): The system only supports user mappings in the IDMU domain.

    IDMU Search Timeout Duration (s)

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

    [Value range]

    5~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 the information of user mappings.

    [Value range]

    The directory contains 0 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 the original user to the target user based on a mapping relationship for accessing shares across protocol.

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-43 explains the related parameters.

    Table 3-43  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

    The original user in a mapping.

    [Example]

    sourceuser

    Target User

    The target user in a mapping.

    [Example]

    targetuser

  5. Click Add, and set the Priority.

    NOTE:
    Priority: A smaller number indicates a higher priority. When multiple mappings share the same original 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.

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

  • 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 user name command to create a user.

  • If the NFS client uses NFSv4, enable the NFSv4 service in the storage system and enter the domain name based on the specific environment:
    • In non-domain or LDAP environment, enter the default domain name localdomain.
    • In an NIS environment, the entered information must be consistent with 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 has been added to the AD domain.

Context

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

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

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

Table 3-44  Example of data planning

Item

Planned Value

Description

File system

  • Name: share_dir
  • Permission: The default permission settings are used.

In this example, the shared directory is configured with the default permissions.

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. Optional: Create a file system.
    1. Select Provisioning > File System.
    2. Create a file system named share_dir as planned.
  3. Optional: Create a local authentication user and record its ID and the ID of its owning primary group.
    1. Select 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-7  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-8  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. Select 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. Select Provisioning > User Authentication > User Mapping.
    2. Click Mapping Parameters and set Mapping Mode to Local system user mappings are supported preferentially.

      Figure 3-9  Configuring user mapping parameters

  6. Configure user mapping rules.
    1. Select Provisioning > User Authentication > User Mapping.
    2. Click Create and configure user mapping rules as planned.

      Figure 3-10  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. Follow instructions in Accessing CIFS Shares to 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. Follow instructions in Accessing NFS Share to 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 d GID as the local authentication user group.
    3. Run the useradd -u 100001 -g 100000 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 user name command to create a user.

  • If the NFS client uses NFSv4, enable the NFSv4 service in the storage system and enter the domain name based on the specific environment:
    • In non-domain or LDAP environment, enter the default domain name localdomain.
    • In an NIS environment, the entered information must be consistent with 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-11 to configure related parameters.

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

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

Table 3-45  Example of data planning

Item

Planned Value

Description

File system

  • Name: share_dir2
  • Permission: The default permission settings are used.

In this example, the shared directory is configured with the default permissions.

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.

Procedure

  1. Log in to DeviceManager.
  2. Create a file system.
    1. Select 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. Select 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-12  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-13  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. Select 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. Select Provisioning > User Authentication > User Mapping.
    2. Click Mapping Parameters and set Mapping Mode to Local system user mappings are supported preferentially.

      Figure 3-14  Configuring user mapping parameters

  6. Configure user mapping rules.
    1. Select Provisioning > User Authentication > User Mapping.
    2. Click Create and configure user mapping rules as planned.

      Figure 3-15  Configuring user mapping rules

  7. Use an NFS client to mount the share and set permissions of files under the shared directory.
    1. Follow instructions in Accessing NFS Share to 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 d GID as the local authentication user group.
    3. Run the useradd -u 100002 -g 100000 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 files soft.txt and hard.txt and run the ln command to point soft link soft_file and hard link hard_file to the two files 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. For details, see Accessing CIFS Shares.
    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-08-14

Document ID: EDOC1000084198

Views: 44594

Downloads: 839

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