Reply to Message

Reply to Message

View discussion in a popup

Replying to:
pabromitis
1 Nickel

Re: Ask the Expert: SMB Protocol on an Isilon Cluster

To get the ball rolling, have you ever wondered what the most common support case for SMB we get is?

Permissions!

Permission cases make up about 25% of our overall case work.  I have found that we can split permission cases into two types of case:

1.) General Windows Permission

2.) Multi-Protocol Permission

With general windows permission cases, troubleshooting the issue should be the exact same way as you would troubleshoot a permission issue on a windows server.  Therefor, it is important to understand how share permission and file system permission interact with each other.

For multi-protocol permission issues, it becomes more complex as Isilon OneFS has a very advanced ACL Policy that can be configured.

I will not get into the details of our AIMA (Authentication, Identity Management, Authorization) engine here as that will be covered in a future Ask The Expert event.

I will however provide some general pointers to troubleshooting a permission problem.

The first thing I like to do is connect to Start -> Run ->  \\cluster (do not add a share to the end)

The reason I connect to just the root of the cluster is because it is a good way to test Authentication.  If the connection fails, you should stop troubleshooting a permission problem and focus you efforts on authentication.

After you have proven that you can connect to the cluster without any issues, I collect the following data to determine why permission is being denied:

1.) Collect the Unix version of the Users Token (this may not return anything if multi-protocol is not in use:

    For 6.5

    isi auth mapping token --name=username

    For 7.x

   isi auth mapping token --user=username

2.) Collect the Windows version of the Users Token (Note the \\ between domain and username)

    For 6.5

    isi auth mapping token --name=domain\\username

    For 7.x

    isi auth mapping token --user=domain\\username

3.) Collect the share output

    For 6.5

    isi smb permission list --sharename=<problem share>

    For 7.x

    isi smb shares view --share=<problem share>

4.) Collect both ls -led and ls -lend output of the problem file and each directory above it

     ls -led /ifs/data/file1.txt

     ls -led /ifs/data

     ls -led /ifs

     ls -lend /ifs/data/file1.txt

     ls -lend /ifs/data

     ls -lend /ifs

Once you have collected the data above, the process to resolve the permission problem is as follows:

1.) Note the Group Memberships the user is a member of from Step 1 and 2

2.) Verify the user is either directly in or is a group member of an entry in the share permission in step 3

3.) Verify the user is either directly in or is a group member of an entry in files system permission in step 4

To provide an example, lets say that I have a user Pete who is unable to write to a share:

1.) Collect isi auth mapping output

isi-ess-east-1# isi auth mapping token --name=domain\\pete

Initial name: pete

Final Token                                                                                 

--------------------------------------------------------------------------------------------

Primary uid: pete (1502)

Primary user sid: pete (SIDSmiley Frustrated-1-5-21-321531391-2185564565-1823270536-1014)

Primary gid: pete (1502)

Primary group sid: SIDSmiley Frustrated-1-5-21-321531391-2185564565-1823270536-1000

On-disk user identity: pete (1502)

On-disk group identity: pete (1502)

Additional Identities:

    admin (GID:10)

    unixusers (SIDSmiley Frustrated-1-5-21-321531391-2185564565-1823270536-1029)

    unixusers (GID:2003)

2.) Collect the share permission output:

isi-ess-east-1# isi smb permission list --sharename=ITGroup

SMB Share Permissions:

Sharename:      ITGroup

        Account                    Acct Type  Perm Type  Permission 

        Everyone                   Builtin    Allow      Read          << Pete is a member of Everyone

        staff                      Group      Allow      Full Control  << Pete is not a member of staff

3.) Collect ls -led and ls -lend ouptput of the paths (I am truncating the otuput)

isi-ess-east-1# ls -led /ifs/data/itgroup

drwxrwxrwx +  2 root  wheel  0 Jul 15 09:33 /ifs/data/itgroup

OWNER: user:root

GROUP: group:wheel

CONTROL:dacl_auto_inherited,sacl_auto_inherited,dacl_protected

0: user:root allow dir_gen_all

1: creator_owner allow dir_gen_all,object_inherit,container_inherit,inherit_only

2: group:Administrators allow dir_gen_all,object_inherit,container_inherit

3: everyone allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit << Note this gives the Everyone Group Write Permission

4: group:Users allow dir_gen_all,object_inherit,container_inherit

Therefor, the problem in this scenario is at the share level.  Pete is a member of Everyone and gets Read at the share which overrides the File System Permission of Everyone Read/Write.  Thus, Pete can only read, not write.

I hope this helps; Happy Permission Troubleshooting!