I assume that the 2 domains are trusted, correct?

isilon5-1# mkdir /ifs/test

isilon5-1# isi smb share create testshare /ifs/test

isilon5-1# isi smb share permission create testshare chris@datadobi.net -d allow -p change

The cluster in my case belongs to a child domain, demo.datadobi.net.  The user I added is my account from the parent domain, so of course it's a 2-way trust.

Your failed syntax from above should be more like this:

isi smb share permission create testshare1 --sid S-1-5-15-70cd0fe5-61e22ca0-17c15952-4b3a -d allow -p change --zone System

But then again that's a problem, because your SID is in HEX, the cluster and the generally accepted standard is to use SIDs that are in decimal, so you need to convert those values, or assuming there is a trust, just use their username as I did in my example.

For troubleshooting purposes, you can verify the username to SID mapping on the cluster directly.

Note the syntax is domain\\username. The first slash is an escape character.

--Edit for some reason the image didn't insert correctly--

isilon5-1# isi auth mapping token datadobi\\chris | head

                   User

                       Name: DATADOBI\chris

                        UID: 10012

                        SID: S-1-5-21-XXXXXX-YYYYYYY-1146100301-1121

                    On Disk: 10012

Hope that helps.

~Chris

Principal Pre-Sales Engineer, Datadobi

chris.klosterman@datadobi.com

Thank you for your response. Yes the 2 domains are trusted. The cluster is joined to the child domain, and the user accounts are in the child domain.

I was hoping to use the SID as spit out from the VNX to save the step of translating through a sidmapper or using –secmap on the VNX to get the domain\username. With the sheer number of shares, and granular share permissions, this is a daunting task.

Unless there is some other super-secret tool or method to copy/translate share permissions from a VNX (file) to Isilon?

Dawn

Thank you for your response.  Yes the 2 domains are trusted.  The cluster is joined to the child domain, and the user accounts are in the child domain.  I have successfully modified shares to add permissions using the username.

I was hoping to use the SID as spit out from the VNX to save the step of translating through a sidmapper or using –secmap on the VNX to get the domain\username.  With the sheer number of shares (~299), and granular share permissions, this is a daunting task.

Unless there is some other super-secret tool or method to copy/translate share permissions from a VNX (file) to Isilon?

Well, 3 options:

1. Translate those SIDs to hex to decimal.  Do it in bulk in excel or something.  I figured when you listed SIDs with hex values that it probably came from a VNX.  It's the only platform I've ever seen that stores them that way.  Then s script out the share modifications.

2. Use a commerical tool to do this for you.  How are you moving the data?  My company's software DobiMigrate (formerly known as DobiMiner), handles all the share creation and copying over the security from source to target as part of a comprehensive migration.

3. You can try using sharedup.exe which is part of the cifstools pack that always shipped with Celerra and VNX, and is likely still available on support.emc.com. But if even a single one of your shares contains a local user or group, the tool will be unable to create that local user or group on the target, and will crash with no indication of why or where it was in the process.

Just a suggestion; hope it helps, if you want to talk about option #2, drop me an email.

~Chris Klosterman

Principal Pre-Sales Engineer, Datadobi

chris.klosterman@datadobi.com

In 8.0.0.4 I used --sid=SID:S-1-1-0

--permission=change

--permission-type=allow

Just to be sure it is not a typo

Hi SKT-

Thank you for clarifying the syntax.  Unfortunately, I still have seem to have an issue with adding in the user SIDs.

NAS-1# isi smb shares permission create testshare1 --zone=System --permission-type allow --permission change --sid S-1-5-15-70cd0fe5-61e22ca0-17c15952-4b3d

Failed to create persona 'SID:S-1-5-15-70cd0fe5-61e22ca0-17c15952-4b3d'

It does seem to accept Well Known SID's, though.  The following command did not show any errors, and added an account "This Organization" with read-write access to the share.

NAS-1# isi smb shares permission create testshare1 --zone=System --permission-type=allow --permission=change --sid=S-1-5-15

NAS-1#

Thanks!

you are still missing "SID:"

Here is the command with "SID:"

NAS-4# isi smb shares permission create testshare1 --zone=System --permission-type=allow --permission change --sid=SID:S-1-5-15-70cd0fe5-61e22ca0-17c15952-4b3d

Failed to create persona 'SID:S-1-5-15-70cd0fe5-61e22ca0-17c15952-4b3d'

NAS-4#

Thanks!

It's not the "SID:" prefix.

As Chris said, the numeric fields have to be in decimal, like 1892487141 for 70cd0fe5.

I suspect even the 15 was given in hex, so in decimal it would be 21 (= 1 * 16 + 5)

-- Peter