NFS/CIFS permission (or AD and NIS user ID translation problem).

Hi HT,

This is well discussed topic - you may find some old thread on the Multi-protocol access.

However, coming to your question, for a true Multi-protocol requirement (CIFS and NFS access on same file system) - it is recommended not to use the usermapper service on the NAS data mover, which maps each domain authenticated Windows User to a UID/GID.

The issue here is, for Windows users, the UID/GID mapped by usermapper service are on a higher range and assigned automatically. You don't have control on that.

Whereas, Unix users using NIS have a different UID/GID. So, if you consider Sandip being the user - gets two different UID/GID while coming from UNIX and Windows. So to NAS - these two are different users (as UID is different) - so the permission and access issue will be there. If I create a file from Windows, I may not be able to modify the file from UNIX although my login name is same - but the UID will be different.

User mapper is mainly for CIFS only environment. For Multi-protocol environment, usermapper should not be used. In stead, the other ways of user mapping need to be used - like mapping all Windows users in NIS and using NIS with the NAS or using Extended AD schema to assign UID/GID to all Windows Users or even using local passwd/group files on the Celerra.

Please review the following documents for more details and also if required, engage your EMC Technical Consultant for more help and guidance.

1) "Managing Celerra for a Multi-protocol Environment" technical document on Powerlink or Documentation CD
2) "Configuring Celerra User Mapping" technical document on Powerlink or documentation CD
3) Online Help Page for Celerra Management MMC Snap Ins (available on Tools and Application CD)

Hope this helps.
Cheers,
Sandip

Great - so you found the difference.

This passwd file is the one I referred to my earlier post of using local passwd/group file for doing the user mapping. Ideally speaking, it should not run with usermapper service, as there may be gap or issues going forward, but your existing setup is using both the passwd file and Usermapper service.

Also note that, passwd file is checked before user mapper in the order by which Data mover checks for Windows users mapping (in fact secmap is checked first then passwd file and User Mapper is checked at the end). So the users who are listed in the passwd file gets the UID/GID mapped as per the passwd file - so they get the same UID/GID coming from WIndows or UNIX and thus no permission issue. But for any new user requiring multi-protocol access, if they are not listed in the passwd file, the UID/GID is mapped by User Mapper thus the UID/GID is different in UNIX and Windows.

You may add these new users requiring multi-protocol access to the local passwd file. Please DO NOT edit the passwd file from the location you mentioned (/nas/quota/slot_x/.etc) - the correct way of adding the user to the passwd file will be -

1) Login as nasadmin
2) su to root
3) run /nas/sbin/server_user server_x -add command to add the new user, enter the UID and GID and comments, if any and hoem directory path if you are using it - you may leave the shell blank.

Another option may to be run server_file server_2 -get passwd passwd_2 command to get the existing passwd file from server_2 to the current directory (target file name I mentioned is passwd_2), then add the new users to the passwd_2 file (following the exact syntaxes) and then put the modified passwd file back to server_2 using the server_file server_2 -put passwd_2 passwd command.

But there may be issue with any user who were mapped earlier by user mapper and now added to passwd file. Any file/folders this user created earlier was having the old UID/GID (mapped by Usermapper) - but now you are changing the UID/GID of that user. However, it seems you have to use this path and tackle any such issues if you face.

Others may provide some valuable suggestions or comments - I should stop now

Regards,
Sandip

I've been digging around and found something interested. I've found /nas/quota/slot_2/.etc/passwd file which is the datamover that the NFS filesystems are on. It has a long list of users (seems like all users accessing both NFS and CIFS share). What's more interesting is ALL users that are HAVING problem DO NOT exist in this file. All (but one and I am asking him to verify) users that NOT having problem exist in this file. Does anyone know what this file used for? What update this file (manually or by somekind of process)? Does it seem to have anything to do with my problem? Can I manually add the users who have problem to this file manually? Sorry for asking too many questions, but I am really clueless at this point.

Thanks again.

Hi Sandip,

Yes I know this is a well discussed topic (you prob. shook your head when you read it) and I did search and printed out your exact response you just posted. I've also been reading the multiprotocal and usermapper docs as well. What got me is that it worked perfectly for some users (users who have been here for years), but not for new user, so there's a file or a mapping service in place already; otherwise, all users are having problem. Can you read the post regarding the passwd file I just posted? Is this THE file that need updated? or Does it have anything to do with my problem?

Thanks
HT

Unfortunately this was done by the people who are no longer here. I am new to the environment and had never worked with Celerra until 6 months ago (with no training), so I don't much about history.

Your comment:
"Also note that, passwd file is checked before user mapper in the order by which Data mover checks for Windows users mapping (in fact secmap is checked first then passwd file and User Mapper is checked at the end). So the users who are listed in the passwd file gets the UID/GID mapped as per the passwd file - so they get the same UID/GID coming from WIndows or UNIX and thus no permission issue. But for any new user requiring multi-protocol access, if they are not listed in the passwd file, the UID/GID is mapped by User Mapper thus the UID/GID is different in UNIX and Windows.".

If this resolves our problem, then I'll document and we'll have to new users to this password file as we go. I don't think that'd be a problem, but thanks for bringing that up. I'll more than likely use the commands you suggested and it should also update the /nas/server/slot_x/passwd automatically?

Your other comment:
"But there may be issue with any user who were mapped earlier by user mapper and now added to passwd file. Any file/folders this user created earlier was having the old UID/GID (mapped by Usermapper) - but now you are changing the UID/GID of that user. However, it seems you have to use this path and tackle any such issues if you face."

What they've done for work-around is creating these files/directories using winscp from windows so these files/directories already have correct permission. I guess I don't need to assign a password for these new users? Sorry for a dump question, but this shouldn't cause any outage by adding these new users, should it?

Hi HT,

I can fully understand your situation and hope you run it smooth without any issue.

Yes - if you add the users on the data mover using server_user command, it will be automatically updated in the passwd file. Also, as I mentioned earlier, it is not encourage to make any file change using the /nas/quota/slot_x path - rather use server_file command to get or put files from/to data mover.

Also note, that we are not assigning any password to any user on the data mover. The entries will only create the user name with UID and GID - since the authentication will be still done at the AD level. Data Mover will check the passwd file (or user mapper database) only for mapping the Windows User to UID/GID - the user has to be authenticated by AD with proper permission to access any data on the NAS.

My last concern was adding any existing Windows users (who have access the NAS earlier and thus was mapped by User Mapper to a UID /GID) to the passwd file. So going forward by adding these users to passwd file (creating users on data mover) may cause some permissions issue later on.

However, to add the users on the data mover there is no downtime required. You can do it online.

Also, as I mentioned before - Do NOT assign any password for the users added to the data mover, authentication will be done by AD not the Celerra.

Hope this helps, please feel free to revert back anytime.

Regards,
Sandip

Hi Sandip,

I need your help again. I thought that was it, but it wasn't (unless there's something else). I exported the passwd file from slot_2 out using server_file, added user to the file, imported it and verified that new user is now in the new passwd file. To be sure I manually copy the new passwd file to /nas/server/slot_2/passwd since it didn't get updated automatically (I've read one thread earlier and EMC suggested to keep /nas/quota/slot_2/.etc/passwd and /nas/server/slot_2/passwd file in sync using vi or cp). I asked user to reboot his WS and still have same problem. Is there some other service (in Celerra, NIS, or AD) that I need to restart? This is just plain Unix passwd file, so it should take it on the fly, shouldn't it? When is this file being scanned? Is it when user logs in to the shares? Am I missing anything else? Any other advise/suggestion?

Thanks for your help.
HT

Yes, /nas/sbin/server_user server_2 -list does see the new user, so we know (or assume) that's ok.

The problem is that the file created in Windows is owned by UID (which matched what in the usermapper file for that user) which is not recognized by NIS UID in NFS mountpoint. It is exactly what you said, regarding the UID was already assigned by usermapper (prior to being add to the local passwd) and it's now in secmap cache. And it made 100% sense.

So it looks like clearing the secmap cache is what I have to head to next. From what you're saying it sounded like secmap cache could be cleared for individual user and not for ALL users? I am afraid that clearing secmap cache for ALL user will cause latency to users since they'll have to go through the whole usermapping process again when first accesssing the share.

If none of this work I'll go through the same process again, but this time using the server_user -add to create accout (of course I'll delete that account first). This way we don't have to assume export/import worked or not.

Would reboot the DM clear secmap cache?

Thanks Sandip for hanging on to this case. It's much appreciated and I think I am getting closer now. Thanks again.

As Ian suggested can you please provide the entries in the nsswitch.conf file on the data mover - it will show the order of User mapping resolution.

One more addition, there is a global SID Cache on the Data mover apart from secmap cache. These two cache are checked first by default before checking the passwd file. So, the entry of the user resides on either of these cache.

Rebooting data mover does not clear any secmap or data mover cache.

I guess the secmap entry can be removed on an individual user - but, deleting entire secmap cache can also be helpful - it may cause a little bit latency though.

However, I'll suggest to get in touch with EMC support now - all these are high level support tasks and should be performed by experienced EMC support engineers - I guess L2 Support team will do this, if required.

Ian or Bill may provide you more details and guidance. Request Ian and/or Bill or any others in the forum to provide valuable comments/suggestions.

Thanks,
Sandip

The DM should attempt to read the passwd file each time a user connects and it needs to get a mapping, so your update should take effect immediately. What does the line you added look like? And what does a "working" one look like? Perhaps the line needs a little modifying. Depending on your configuration, for example, you may need to append the CIFS domain name to the user name for the DM to map the user properly, but all of your entries should work that way.

Doing the server_file -get, edit, then server_file -put definitely should be enough, too. The copy of the "passwd" file in /nas/server/slot_2 is more or less a backup. It's pulled from the DM every hour by the "NASDB Backup" process. The DM doesn't read this file directly (or even indirectly), and you don't need to worry about it.

Are you using NIS? Perhaps you're actually using NIS and not local passwd/group files for mapping, and the files are just left over from a previous configuration. By default we'll attempt to look for mappings in BOTH, if they're configured, though, and someone would have had to intentionally turn off looking at local files. There may be a file called "nsswitch.conf" on your DM that defines where we look for mapping info. Does one exist (it's in the same place as the passwd file, or you can get it through server_file -get)? What does it say?

Do you see errors in the server_log for your DM when the user tries to connect?

Sandip/Lan,

I am trying to answer all the questions that you asked as best as I can, please let me know if I've missed anything else

These are the entries from the local passwd file

Entries for working user:
ut02183:*:1058:5020:name:/home/ut02183:/bin/csh
ut02183.vn:*:1058:5020:name:/home/ut02183:/bin/csh

Entries for non-working user (recently added)
ud0114v:*:6465:4000:name:/home/ud0114v:/bin/csh
ud0114v.vn:*:6465:4000:name:/home/ud0114v:/bin/csh

I basically copied the lines and change the username, then imported (put) it.

Yes, we're using NIS for Unix.

Your comment:
"Perhaps you're actually using NIS and not local passwd/group files for mapping, and the files are just left over from a previous configuration. By default we'll attempt to look for mappings in BOTH, if they're configured, though, and someone would have had to intentionally turn off looking at local files."

Is there a way to verify if what (NIS and/or local passwd or neither/both) is being used? Is there a daemon on CS?

No, I can't locate nsswitch.conf anywhere

[nasadmin@usgsox002cs nasadmin]$ server_file server_2 -get nsswitch.conf slot_2.nsswitch.conf
server_2 : /.etc/nsswitch.conf:
Error 2: server_2 : No such file or directory
[nasadmin@usgsox002cs nasadmin]$

I've already engaged EMC yesterday and got no response so far. I just called back for status and got requeued.

Thanks guys.

Then most likely my previous explanation holds good that the cache is getting hit first before the passwd file is checked.

I am sure you 'll get an response from NAS support shortly and explain them the situation and try to get the cache entry removed for non-working users or clear the entire cache.

However, I am sure by now you got the details and idea of having issues with user-mapping in multi-protocol environment and why it is not recommended to run UserMapper in multi-protocol environment.

Have a wonderful weekend.
Regards,
Sandip

I want to apologize and clear up something. When you guys asked "Are you using NIS", I was thinking you asked the NIS server for Unix users and that's why I said yes. I now just found out that you can use NIS within the DM (and this is prob. what you were asking). If so, then no we are not using NIS the celerra

[nasadmin@usgsox002cs slot_2]$ server_nis ALL
server_2 : no entry
server_3 : no entry
server_4 : no entry
server_5 : no entry
[nasadmin@usgsox002cs slot_2]

Anyway, support called back and I explained what you've educated me. We looked at the secmap cached for those users who are having problem and their UIDs in cache don't match with NIS UID (which is what we expected). Support is now looking into how to clear or even update these users' UIDs in secmap cache to match with what NIS has. To be sure I'll ask users to shutdown (or at least stop using the share) before or while this is done so the next time they access the share, the UID should be read from local passwd file then will be stored in cache.

I really hope this does it and thanks for ALL the help and education you both provided. I'll give you an update after eveything done and hopefully just good news and no more questions (can't promise) :~)

Thanks and have a wonderful weekend.
HT

Hi HT,

Hope things are working great at your end. Please let us know, if there is any more update.

Thanks,
Sandip