unity migration vdm,usermapper,multiprotocol questions

cool,

is there a link to document for light reading for weekend ?

Not sure what document Rainer was referring to but if you go to this link and select the Documentation link that will lead you to all the Unity documents.

https://support.emc.com/products/39949_Dell-EMC-Unity-Family

glen

From Dell EMC Unity: Configuring Multi-protocol NAS Server (User Correctable) Article Number 000501603 (https://emcservice.force.com/CustomersPartners/kA5f1000000XZXaCAO )

2. If, after the server has been successfully configured, the SMB users are unable to access the shares, this reason would be caused by not having IDMU installed and configured. This is required in order to map the SMB users to the NFS side for proper configuration. This is explained further in KB 491184.

My read of this is If a windows share has to be multiprotocol, then it needs to be created on a multi-protocol NAS Server. However if a windows user does not have a corresponding unix account that secmap can use, access will be denied.

This differs from VNX behaviour as secmap created a local UID reference to ‘hide’ the lack of a unix account rather than simple deny SMB  access Is this a correct read ? and it so explains the lack of any references to secmap import during VNX migration.

Dell EMC Unity Family Configuring Multiprotocol File Sharing

https://support.emc.com/docu86369_Dell_EMC_Unity_Family_Configuring_Multiprotocol_File_Sharing.pdf?language=en_US

castleknock wrote: This differs from VNX behaviour as secmap created a local UID reference to ‘hide’ the lack of a unix account rather than simple deny SMB  access Is this a correct read ? and it so explains the lack of any references to secmap import during VNX migration.

The difference isnt in secmap

secmap is not a mapping method - its merely a cache so that we dont have to do repeated calls to external mapping sources which can take time and CPU cycles

The difference is with usermapper

usermapper was designed as a "mapping method" for CIFS only file systems but on VNX/Celerra this wasnt enforced.

The manuals told you clearly to disable usermapper if you are doing multi-protocol but many customers didnt do that - either because they didnt know of out of convenience

So they are using a config where some users were mapped through the AD/NIS/ntxmap and the ones that couldnt got a uid from usermapper

In Unity we improved this:

usermapper is per NAS server - and not globally per data mover

by default usermapper is disabled for multi-protocol NAS server

instead we add options for default Unix/Windows user that get used if AD/NIS/ntxmap are unable to map the user - which didnt exist in VNX/Celerra

So if you use the default on a multi-protocol NAS server and we cannot map a user then access is denied

You an then either:

- make sure this user is covered by the mapping sources

- configure the default Unix user

- enable automatic user mapping (usermapper)

this is explained in detail with flowcharts in the multi-protocol manual that I mentioned

keep in mind though that just enabling usermapper like on VNX is convinient but it also makes changes and troubleshooting more difficult

This is because secmap entries never expire or get updated

For example if  a user connects to a NAS server before you have configured its account in AD/NIS/ntxmap mappings he will get a UID from usermapper

Then if later the admin adds the account to AD/NIS/ntxmap this account will still use the uid from usermapper for this NAS server but on a new NAS server the uid from the mapping source

Also since usermapper is now per NAS server the same user will get different uid's on different NAS servers

bottom line - if you want full multi-protocol then use a deterministic mapping method and not usermapper