Unsolved
This post is more than 5 years old
29 Posts
0
5017
CIFS and NFS multiprotocol
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?
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?
nandas
1.5K Posts
1
August 14th, 2007 10:00
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.
Thanks,
Sandip
Message was edited by:
Sandip
nandas
1.5K Posts
0
August 14th, 2007 11:00
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.
Thanks,
Sandip
nasgurunot
29 Posts
0
August 14th, 2007 11:00
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?
FresnoRed
90 Posts
0
August 15th, 2007 10:00
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.
Good luck,
Harold
Rainer_EMC
8.6K Posts
0
August 15th, 2007 12:00
There are several possiblities - take a look a the CIFS multi-protocol and the usermapping manual.
It really depends on what your primary environment is, where you change permission and how you want to do user mapping
for the chmod/chown - make sure you have that file system root exported to the client
there also is a norstchown param - by default only the owner a file is allowed to use chown (except root)
nasgurunot
29 Posts
0
August 22nd, 2007 08:00
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?
nandas
1.5K Posts
0
August 22nd, 2007 09:00
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?
Thanks,
Sandip
Rainer_EMC
8.6K Posts
0
August 24th, 2007 08:00
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