Unsolved
This post is more than 5 years old
11 Posts
0
12975
January 20th, 2011 08:00
setup proper default permissions for nfs share
hi,
I have a Celerra nx4 with an nfsv4 share and am having trouble setting up default permissions for clients. When I create a file on the share another user in my environment cannot change the permissions on the FSO. We're a linux/unix environment and do not want ldap, nis, ad, or any directory server involved. I was looking into usermapping, but someone from support told me this is only a feature of CIFS shares. Can someone help me in setting up my nx4 so that ownership and groupship is squashed on my share so that everyone who accesses it can make changes to it? I saw that I can create a local usermap file, and am also wondering if that will be global to my nfs file system, seems like it effects the data mover more than anything...and if so, can someone give me documentation on the syntax of how to generate this file? Thanks. Here's a snippet of what I'm talking about... I also tried changing the root host and rw hosts in the properties for my export but that doesn't seem to do what I want either.
ws19:test dennishuynh$ pwd
/Volumes/nx4/test
ws19:test dennishuynh$ ls
ws19:test dennishuynh$ whoami
dennishuynh
ws19:test dennishuynh$ touch test
ws19:test dennishuynh$ ls
test
ws19:test dennishuynh$ ls -al
total 3
drwxrwxrwx 2 dennishuynh wheel 80 Jan 20 11:12 .
drwxrwxrwx 5 root wheel 1024 Jan 20 11:12 ..
-rw-rw-rw- 1 dennishuynh wheel 0 Jan 20 11:12 test
ws19:test dennishuynh$ su jun
Password:
OsX
ws19:test jun$ ls
test
ws19:test jun$ chmod 755 test
chmod: Unable to change file mode on test: Operation not permitted
ws19:test jun$
Rainer_EMC
6 Operator
•
8.6K Posts
0
January 20th, 2011 14:00
there is no squash on the Celerra - you need to configure your user accounts properly on the clients or remap there
Rainer_EMC
6 Operator
•
8.6K Posts
0
January 20th, 2011 15:00
the only UID mapping for NFS the the Celerra does is for root / anon
IMHO the Linux squash options are "hacks" for broken environments - they were never in the NFS standard
Rainer_EMC
6 Operator
•
8.6K Posts
0
January 20th, 2011 15:00
in order to use NFSv3 just remount the file systems with NATIVE access policy and change the export to v3 or change the clients to mount with v3
Rainer_EMC
6 Operator
•
8.6K Posts
1
January 20th, 2011 15:00
for NFS only the clients umask counts - the client sends the UID/GID and perms it wants on a create numerically in the NFS request and the server just takes it verbatim
the Celerra umask only plays a role when we don't get Unix perms like on a CIFS create
you need to work with the Unix u-g-o model - so if another user needs access he has to be either in the same group and allowed with the group perms or through the other perms
you should be able to "fix" it using the setgid bit on the directory so that newly created files get the GID of the dir and not from the NFS request (I haven't tried that on a Celerra for a long time) and a umask on the clients withe the appropriate rights for the group
bdiuser
11 Posts
0
January 20th, 2011 16:00
these solutions seem more like a hack than anything. it may have been a hack when created, but its become the norm...
creating user accounts properly on the client? Anything other than the default way of creating users or remapping every client is a hack...
Since the umask on the Celerra is only for CIFS then that doesn't help either.
no sorry, group ownership is not being inherited so i don't think fixing a setgid bit will work either. unless you have specific instructions on how to do this, its not working for me.
umask on the clients with the appopriate rights for the group? sorry confused...
the only UID mapping for NFS the Celerra does is for root / anon -- ya that's what i figured, which seems like a huge security hole... and didn't seem to work when i tried. provide with how to do this secifically please, and if it works...perhaps we can use it for the meantime until we a proper ldap server up. even though, i'm not too confident it will work with my mac and linux environment.
how do you change the export to v3? didn't see an option for it with the server_export command. i just disabled nfsv4 and recreated a new export and it doesn't appear to be setup anymore.
back to the hacking topic...all of this seems very complicated and for the most part are all client-side hacks i need to do in order to conform to this server. there needs to ocnfigure this on the server! I've already switched to nfsv3 with no luck either. i'd prefer to hack the server(even though i shouldn't even consider this because its brand new technology) instead of hack the volume of clients. Please tell me there are no other options and I will happily move onto finding another solution. because of my lack of knowledge on this equipment however i hesitate to do so because i feel a nas cannot be this poorly designed and am willing to absorb more documentation then i need to before i call it quits.
so please confirm - there is no way to route all users to one user on the celerra?
i really appreiciate your help rainer, just very frustrated at this point. after installing...im now faced with having the pull it out and send it back.
thanks!
bdiuser
11 Posts
0
January 21st, 2011 09:00
please explain to me what are my options with the given environment please...
thanks!
Rainer_EMC
6 Operator
•
8.6K Posts
1
January 23rd, 2011 14:00
Now if I understand your current setup correctly here is what I think your options are:
1) set all the clients default umask so that all new files get created with RWX for other
2) put all user accounts that need access into one group and make this the primary group for them and set the clients umask to have RWX for the group
(primary group because thats what determines the group owership for a file)
3) if you dont want to change the users primary group then on the top-level directory set the setgid bit and make it owned by a group
that each user belongs to like "chgrp sharedgroup dir; chmod g+s dir" and set the clients umask to rwx for group
This way every file created in that directory tree is created with the group owner of sharedgroup
That should work out so that each user can access files create by another user
You might want to also set the param filesystem.rstchown on the Celerra - this way at least the ower of a file is allowed to change its owner/group
The fact that only the owner (or root) is allowed to change the owner or perms you cannot change
hope this helps
Rainer
Rainer_EMC
6 Operator
•
8.6K Posts
0
January 23rd, 2011 14:00
ok - lets understand Unix and NFS security first
Authentication is client based (unlike Windows) so a user gets authenticated by the client when he logs in. At that time the client uses local files, NIS, LDAP, ... to verify the users password and gets his UID, primary GID and the like of GIDs he belongs to
Now each NFS request that gets sent to the NFS servers carries these credentials as numerical values
The NFS server export options for a share determine whether a client workstation (not user) has readonly, read-write or no access in general.
It also determines via the root= option from which client workstations root UID/GID will be taken as root or mapped to anon
The NFS server takes them at face value and compares them to the file/dir perms to determine access
In case of root it actually doesnt even check - root is god in Unix and is allowed everything no matter what the perms say
If the UID in the NFS request is the same as the UID on the file/dir then user part of the u-g-o permissions are applied
if the GID is the same as on the file the the group part is applied
any other case the other perms apply
In order to change a file/dir's permissions or ownership you have to be the owner (or root)
In the Unix model if you want multiple accounts to have access to a set of files you typically create a group that each account is a member of and set the client umask so that the default perms for newly created files have rwx perms for the group
Now mapping all UID/GID to the same value on the server make the whole Unix security model useless - you can no longer track who owns (created) a file and the permissions are no longer effective
The few users that want that typically let just everyone work as root or the same UID/GID
Rainer_EMC
6 Operator
•
8.6K Posts
0
January 23rd, 2011 14:00
Of course you can also file a Product Enhancement Request for all_squash functionality and/or escalate via Sales - but that doesnt help short-term
yogad
78 Posts
0
June 30th, 2014 08:00
Is it how the Isilon clusters are configured in your environment ?
Rainer_EMC
6 Operator
•
8.6K Posts
0
June 30th, 2014 09:00
last post on this thread is over 3 years old - do you really expect an answer ?
yogad
78 Posts
0
June 30th, 2014 09:00
I wish
. I am working on NFSv4 as well with Isilon and really not sure how to with ID mapping and stuff. I have googled on it, but it does not make much sense to me
Rainer_EMC
6 Operator
•
8.6K Posts
0
June 30th, 2014 10:00
There is a different forum for Isilon