I am unable to create a writeable SMB share. What am I doing wrong?

Question

Hello,I have found that suddenly the usual procedure for creating SMB shares is not working on an Isilon cluster. I have found an excellent instruction on troubleshooting permission in an 'Ask the expert' thread on this forum. However could not understand what is going on. Perhaps one of the reasons of my failing to spot the issue is that Ask the expert example is referring to OneFS 6.5 and I am on OneFS Version: 7.0.0.0.My issue is that no SMB user seems to be able to write into shares that I am creating.Here is what I do:Add a directory smb-test using the File System Explorer in the existing directory /ifs/other.Set owner user name to joe and group to staffGive all permissions to owner and group and read and execute permissions to everyoneCreate a new SMB share smb-testChanging Directory ACLs to Do not change existing permissions instead of Apply Windows Default ACLs Add Full access to user joe and read/write access to group staff.Now I connect to the share using the credentials for joe with smbclientsmbclient -U joe //ds.domainname/smb-testhowever I am unable to create a subdirectory or put a file onto the share, since I am gettingsmb: \ mkdir test NT_STATUS_ACCESS_DENIED making remote directory 	estThe only way I could make it work was to allow write access to everyone by issuing a CLI commandisi-ds1# chmod +a everyone allow dir_gen_write smb-testI have performed the usual diagnostics steps by issuing the CLI commands1) isi-ds1# isi auth mapping token joe2) isi-ds1# isi smb shares view --share=smb-test3) isi-ds1# ls -led /ifs/other/smb-test4) isi-ds1# ls -lend /ifs/other/smb-testThe output is attached.I have tried also to create a share with Windows Default ACLs but that share also returned permission deniedI have tried to connect to the share from a genuine Windows machine to factor out possible issues with smbclient but received the corresponding 'Try again' dialog box.I am running out of ideas what else could be wrong and would welcome any feedback.

dimch · Answer

Thank you for the answer. However this, I understand, makes the directory writeable to everyone not just for user joe.

What I am observing by doing this is however is that joe authenticated with his password through smbclient or Windows Explorer is seen as nobody by the file system. I.e.

smb: \testdir\> mkdir test

smb: \testdir\> showacls

smb: \testdir\> dir test

FILENAME:test
MODE:D
SIZE:0
MTIME:Fri Jan 10 21:37:24 2014
revision: 1
type: 0x8004: SEC_DESC_DACL_PRESENT SEC_DESC_SELF_RELATIVE 
DACL
     ACL     Num ACEs:     1     revision:     2
     ---
     ACE
          type: ACCESS ALLOWED (0) flags: 0x00 
          Specific bits: 0x1ff
          Permissions: 0x1f01ff: SYNCHRONIZE_ACCESS WRITE_OWNER_ACCESS 
                 WRITE_DAC_ACCESS READ_CONTROL_ACCESS DELETE_ACCESS 
          SID: S-1-22-1-65534

     Owner SID:     S-1-22-1-65534
     Group SID:     S-1-22-2-65534

          32787 blocks of size 0. 9191 blocks available

smb: \testdir\>

Note the SID S-1-22-1-65534 which is the SID of user nobody on the UNIX system.

isi-ds1# ls -led /ifs/other/smb-test/test

drwx------ +  2 nobody  nobody  0 Jan 10 21:37 /ifs/other/smb-test/test
 OWNER: user:nobody
 GROUP: group:nobody
 0: user:nobody allow dir_gen_all

So my problem really is how to make my authenticated Windows users be seen by the filesystem as what they have authenticated for.

chughh · Answer

NTFS permission needs to be given for write chmod +a group everyone allow generic_all,dir_gen_all smb-test

dimch · Answer

So it was 'Impersonate Guest' set to 'Always' by default. Changed that to 'Never' and it works. Always need to check if isi smb shares view --share=smb-test returns              Impersonate Guest: always And if it does, change that to never.

Isilon

Was this post helpful?