I mounted a filesystem via NFS on a unix server. I wanted to change the permissions and ownership of the files that it would look like this: root:adm, chmod 775 /test. When I try to change the group back to root, it says I am not the owner. However, when I unmount the filesystem, I can change it to root group but the group goes back to adm when I mount the filesystem again.
When I take the same share and export it on CIFS, I cannot drop, delete, or change a file. In the Security Tab of the ACE, I get as follows: Everyone with allow/deny all unchecked and grayed out. UNIX GID=0X4 with allow/deny all unchecked and grayed out UNIX UID=0x0
How can I make this work that it works for the users on both unix and the windows CIFS? What are my options? How does Windows understand the Unix permissions/privileges?
This is no doubt a good topic. First of all - you are requesting for a Multi-protocol environment - with both CIFS and NFS access on the same file system - which is definitely more challenging one. The most important part here is the User-Mapping issue - which I understand you are hitting here.
The file systems on NAS are basically UNIX file system - while accessing these from another UNIX client over NFS - there is no issue of UID/GID mapping as each user in Unix world has a UID/GID and it deals with Owner/Group/Others permission on each file and/or folder with Read/Write/Execute.
But when you want to access a file system on NAS from Windows client (using CIFS) - there has to be some user mapping - by virtue of which each Windows user has a unique UID/GID assigned. In windows world there is no concept of UID/GID - instead it is SID( Security Identifier) which defines all permissions, rights, access etc associated to each windows user.
So, in order to access the NAS data from Windows, the User mapping service needs to be in place. On NAS, we have "usermapper" service running on each data mover, which takes care of Windows User mapping automatically allowing each domain authenticated user to access the File/folder on NAS.
But in a multi-protocol environment, in most cases, you can not run the usermapper service on NAS. As Usermapper will map each domain user to a UID/GID from its own pool (significantly high number) which most likely will not match with your UNIX UID/GID. So, the user name "sandip" in UNIX world may have UID as 551 - but usermapper, if allowed to run may map windows user "sandip" as UID 30051 - which means, to NAS these are two different accounts when accessed from Windows and UNIX.
So, if I create a file from UNIX - the ownership of the file will be with UID 551 - but if I want to access the file from Windows - I may not be able to as I am a different user now with UID 30051.
In your case, the share was created from Unix end using Root - UID 0x0 - which is not a valid user coming from Windows world as there is no user named Root in the AD and usermapper can not map this user although from security standpoint (Windows ACL) Everyone has full control.
In nuts, you can not run usermapper on Multi-protocol environment - disable Usermapper will stop all CIFS access unless you have another way of mapping Windows Users.
The other way of mapping Windows users are using Centralized NIS server where all users are defined, or using EMC Tool to expand Active Directory Schema to have UID/GID field defined for each user or to use local passwd file where you can map all Windows users requiring access to NAS with their UNIX UID/GID.
Please refer to "Managing Celerra in a Multi-protocol environment", "Managing Celerra for the Windows Environment" and "configuring Celerra User mapping" documents for more details.
Also, please engage/consult your EMC team before deploying the multi-protocol environment.
Suppose I went with the local password file on the NAS, would the access still work for just CIFS share that is not a part of the NFS/CIFS multiprotocol. Does this mean that the usermapper service can still run?
Well - this is a question of User Mapping on the NAS. What ever be the mechanism of user mapping - it will be applicable on the entire data mover - you can not separate the user mapping mechanism for share to share (or file system to file system).
It is still possible to have local passwd file as well as Usermapper service - as the NAS will first check Secmap, then the local file for getting UID/GID - if not available on the passwd file - it will refer to other means and usermapper comes at end.
But this is not going to be good solution or design considering the fact that, you don't have any control on the UID assigned by usermapper service. Today, one user may not require Multi-protocol access - so you didn't map him/her in local passwd file - thus usermapper is mapping the UID/GID for that user. But tomorrow, if that user requires multi-protocol access, it will be an issue. To avoid all complexities, issues and problems - it is advised not to run Usermapper in a multi-protocol environment. However, if you stop usermapper service and plan to use local passwd file, you have to map all windows users (may be in hundreds or thousands) to the local file - which is no doubt a pain.
If you have any Unix host where all users are defined in the passwd file, you may simply use the same passwd file from this host and use it on NAS. But ensure, the UID/GID mapped for each user is the same across all boxes.
Another option is, If you have more than one Active data movers - you may turn one data mover to multi-protocol - no Usermapper and use passwd file, where as other data mover(s) can still run usermapper and serve as CIFS only.
Please be very careful while disabling usermapper and removing the entries from secmap on a production box. If required please engage EMC support for the same.
Usrmapper was an issue that almost killed our initial SAN/NAS installation 6 years ago! We also had need to have Unix and CIFS access to common file systems. The fix we (EMC primarily) put in was to use usrmapper on the Control Station (which was the only way to do it at the time.) This gives us a unified UID mapping for Microsoft users. Each month I do a usrmap_control dumpfiles 1 command via a cron job to produce a passwd and group file that I then server_file server_x -put out to the data movers so they can resolve locally.
The only problem this really posses is when a CIFS admin goes into a file structure that also has Unix users and takes ownership. This often causes problems with the Unix access is the user has been depending on ownership rights.
I've been told several times there's a better way to do it, but it's working (and so am I!) so I don't intend to change.
I used the Native access policy. The primary environment is mostly unix but most of the unix filesystems get shared out to the window users. The permission gets changed at the unix level.
What i have seen is that uid on windows and unix do not seem to match up obviously on the unix filesystems as the windows will have a higher uid than the unix. This is what I am trying to accomplish where the uid on unix and windows do match up. Is that accomplished by using the internal or external usermapping?
Usermapper (internal or external) should not be used for this type of Multi-protocol Environment. If you run usermapper, you will not have any control on the UNIX UID mapping - so the same user will have two UID - once assigned by Usermapper and the other in the UNIX world - so NAS will treat these as two different user.
Stop usermapper and use other ways of mapping users. You may Use NIS or Extend the AD Schema using EMC tool or any other tool that provide UNIX UID/GID mapping for AD users or the local files (passwd and group) on the data mover.
If you use passwd file, you need to manually create all windows users on each data mover (using /nas/sbin/server_user command) and map the UID/ GID for each user. Don't put any password for the users and the NAS box will not do any authentication. You may create the users on one data mover and then copy the files from that data mover and put it to other data movers (user server_file command). Also there are few other CIFS marameters which needs to be modified.
Do you have any EMC person helping or supportring you?
but the usermapper doesn't really do any static SID to UID/GID mapping - its just a "distributor" that will give you an unused UID/GID for a new SID from a defined range. It is mainly meant for CIFS only data and the default ranges are designed not to clash with whats commonly used for Unix UID/GIDs
If you require true multi-protocol with coordinated ownership and access controls from both worlds you should use any of the other usermapping solutions: - data mover password files (only used for mapping, not for CIFS auth) - NIS - similar to the password file - LDAP - AD schema extension - regular scripts to generate the password files
Dont change from usermapper to this lightly if you already have data on the box - you would also have to cleanup the ownership and permission on this data
There are cases when you can go with something simpler - like if you only have non-conflicting Windows user names (one domain) *and* the users Windows name is literally the same as the Unix user name
Or if you dont require full security from one side and can live with general permissions