PowerScale: OneFS: How to troubleshoot user permission issues

Introduction

This article provides a procedure to troubleshoot permissions issues in OneFS 6.5 and later. For example, use this procedure when particular users do not have access to data they should have access to (they might receive a "permissions denied" error). This may also be used when users can access or modify data when they should not have such access.

Procedure

This procedure generates an access token that the cluster uses for the specified user, which is then compared to the file system permissions. In this example, the user is a domain user (VMTEST\testuser1).

To generate the access token:

1. Open an SSH connection on any node in the cluster and log in using the "root" account.
2. Run the following command to create the token:
    

   isi auth mapping token --name=VMTEST\\testuser1 -v

    

   NOTE
   When specifying a domain user, you must escape the backslash (\) character by adding another backslash, as in the example above with user " VMTEST\\testuser1." Alternatively, you can enclose the domain username in single quotes and use a single backslash ( 'VMTEST\testuser').

   
   Output similar to the following is displayed:
    

   Initial name: VMTEST\testuser1
   
   Mapping History
   Rules Processed
   -------------------------------------------------------------------------------
   Initial credential:
   cred={SID=SID:S-1-5-21-4087762976-3323942327-742857095-1118,
   GROUPS={SID:S-1-5-21-4087762976-3323942327-742857095-513, GID:1000000,
   GID:1001, SID:S-1-5-32-545, GID:1545} }
   Final credential: cred={SID=SID:S-1-5-21-4087762976-3323942327-742857095-1118,
   GROUPS={SID:S-1-5-21-4087762976-3323942327-742857095-513, GID:1000000,
   GID:1001, SID:S-1-5-32-545, GID:1545} }
   
   Final Token
   -------------------------------------------------------------------------------
   Primary uid: VMTEST\testuser1 (1001)
   Primary user sid: VMTEST\testuser1 (SID:S-1-5-21-4087762976-3323942327-74285...
   Primary gid: VMTEST\domain users (1000000)
   Primary group sid: SID:S-1-5-21-4087762976-3323942327-742857095-513
   On-disk user identity: VMTEST\testuser1 (1001)
   On-disk group identity: VMTEST\domain users (SID:S-1-5-21-4087762976-3323942...
   Additional Identities:
       testgroup1 (GID:1001)
       Users (SID:S-1-5-32-545)
       Users (GID:1545)

   
    

The output shows the mapping rules for the user (in this case, none are defined) and displays information about the access token the cluster generates. The access token is the union of all personas for the user. For example, there is a user that is found in both Active Directory (AD) and Lightweight Directory Access Protocol (LDAP). The output displays security identifiers (SIDs), user identifier (UIDs), and group identifier (GIDs).

To compare token to file permissions:

To compare the token to the permission on a given file or directory, you must view permissions on the object itself. You may potentially have to do this for all parent directories up to the root of the share.

To list permissions for a directory the user can access:

1. Run the following command to list the permissions of <test_dir_access> in long format (l), print the Access Control List (ACL) (e), and list directories as plain files (d):
    

   ls -led <test_dir_access>

   
   
   Output similar to the following is displayed:

   drwxr-xr-x    2 VMTEST\testuser1  wheel  155 Apr 25 17:33 <test_dir_access>
   OWNER: user:VMTEST\testuser1
   GROUP: group:wheel
   SYNTHETIC ACL
   0: user:VMTEST\testuser1 allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
   1: group:wheel allow dir_gen_read,dir_gen_execute
   2: everyone allow dir_gen_read,dir_gen_execute

   
    
2. Run the following command to display the same information as above, but also list user and group IDs numerically ( n):
    

   ls -lend <test_dir_access>

   
   
   Output similar to the following is displayed:

   drwxr-xr-x    2 1001  0  155 Apr 25 17:33 <test_dir_access>
   OWNER: user:1001
   GROUP: group:0
   SYNTHETIC ACL
   0: user:1001 allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
   1: group:0 allow dir_gen_read,dir_gen_execute
   2: everyone allow dir_gen_read,dir_gen_execute

   
    

The output shows the ACLs on the object (if they exist), and the names. It also includes the identity that is stored on disk (the UID/GID or the SID). In this case, there are no ACLs, so the POSIX permissions apply.

In the example output above, the owner of the directory is VMTEST\testuser1. This example uses a default OneFS 6.5 installation, and the on-disk format is native. The user exists in both AD and LDAP and has a real UID; the identity stored is " user:1001." In this case, the user has access to the <test_dir_access> directory.

To list permissions for a directory the user cannot access:

1. Run the following command to list the permissions of <test_dir_noaccess> in long format (l), print the Access Control List (ACL) (e), and list directories as plain files (d):
    

   ls -led <test_dir_noaccess>

   
   
   Output similar to the following is displayed:

   drwxrwxr-x +  2 root  wheel  0 May  9 17:40 <test_dir_noaccess>
   OWNER: user:root
   GROUP: group:wheel
   0: group:VMTEST\domain users deny dir_gen_all
   1: group:VMTEST\domain admins allow dir_gen_all
   2: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
   3: group:wheel allow dir_gen_read,dir_gen_execute
   4: everyone allow dir_gen_read,dir_gen_execute

   
    
2. Run the following command to display the same information as above, but also list user and group IDs numerically ( n):
    

   ls -lend <test_dir_noaccess>

   
   
   Output similar to the following is displayed:

   drwxrwxr-x +  2 0  0  0 May  9 17:40 <test_dir_noaccess>
   OWNER: user:0
   GROUP: group:0
   0: SID:S-1-5-21-4087762976-3323942327-742857095-513 deny dir_gen_all
   1: SID:S-1-5-21-4087762976-3323942327-742857095-512 allow dir_gen_all
   2: user:0 allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
   3: group:0 allow dir_gen_read,dir_gen_execute
   4: everyone allow dir_gen_read,dir_gen_execute

   
    

The output indicates that the user is a member of " VMTEST\Domain Users" and there is a deny access control entry (ACE) for this group, so access is denied.