that is already done.  the problem isn't being able to write to the share, the problem is when i create a file or directory on the share, another user cannot change permission on it.  i want the quickest and easiest way to resolve this problem on an nfs share.  doesn't seem like its possible without the use of usermapping.  can anyone instruct me on how to do this with nfs?  i want a local usermap file where all users are mapped to one user...  thanks.

Don't share out the root of the filesystem.  Create a folder in there, and share this folder out.

Let me know if this helps.

Sebby Robles

EMC Celerra Support

NFSv3 or NFSv4 ? mixed or native access policy?

With NFSv3 and NATIVE its just a question of either having rights through the groups or other permissions as normal in Unix

Rainer

Sorry, its what our current ililon has and already what we invested in.  It's not too late tho, how would I go about setting this up with nfsv3?  So there is no way to map users without the use of Kerberos and ACLs using nfsv4, Are you certain about this? and nfsv3 doesn't require Kerberos and ACLs to map users?  And I was just reading that I may have proplems communicating with already existing nfsv4 shares with an nfsv3?  how will this be effected.  Thanks.

here's my environment.  i have the nx4 celerra and about 20 machines that need to access it.  we're on macs and linux machines mainly.  with no directory service involved, except for the one the os provides, we need all the clients to have access to this share.  if one client creates a file on the share, another client can easily go in and change permissions on this file without the use of the original person who created it.  on our ililon, basically all ther ownership and groupship is squashed in order for this to happen.  if i create a file on my isilon as 'dennis' on my machine, its seen as owned by 'owner' and group 'group'.  if this isn't possible to have done with nfsv4 and nfsv3 is my only option, please let confirm this and i'll roll back to nfsv3 and please provide me with instructions on how to set this up with the given environment.  (this seems so simple, i actually don't need my nx4 to  behave the way my isilon does, but there has to be some way to make this possible between users without overcomplicating it with kerberos and acls)  I think your latter suggestion answeres this, but I'm unsure because this a still new to me.  Thanks.

Is there a specific reason you want to use NFSv4 ?

It does make things more complicated with requiring Kerberos and ACLs compared to good old NFSv3

yes that's what i want, i want user1 on host ux1 to have the same uid as user2 on host ux2.

no, we do not have an NIS or ldap database for name to uid/gid mapping, correct.

Are you saying that user1 on host UX1 can have the same UID as user2 on host UX2?

You do not have any NIS or Ldap database for name to UID/GID mapping, correct?

Claude

Are you saying that user1 on host UX1 can have the same UID as user2 on host UX2?

You do not have any NIS or Ldap database for name to UID/GID mapping, correct?

Claude

i don't care about getting the benefits.  undoing the settings to enable nfsv4 on the control station seems hard then i thought.  i just want it to work without the use of kerberos or acls.  im sorta confused also by what you mean when you mention acls, a central acl?  or the local acl on the  host machines?  if we can use the local acl on the client machine, then that's fine, if central, i don't think that'll happen.  thanks.

No, I am not sure – I would suggest to take a look at the NFS manual available from Powerlink

If you aren’t using Kerberos or ACLs then you aren’t getting benefits from using NFSv4 compared to v3

Rainer

this is how its setup on the isilon

this file squashes all permissions on the isilon, there has got to be a way to do this!!!!!

[root@spartacus ~]# cat /etc/exports
/Volumes/elements    192.168.1.0/255.255.255.0(rw,insecure,sync,all_squash)
/Volumes/facility    192.168.1.0/255.255.255.0(rw,insecure,sync,all_squash)
/Volumes/sources    192.168.1.0/255.255.255.0(rw,insecure,sync,all_squash)
/Volumes/facility/Studio_Images    192.168.1.0/255.255.255.0(rw,insecure,sync,all_squash)

umask on the unix server?  all a umask does is subtract the umask bits from whatever the user logging on's umask is?  what happens when another user with 444 555 wants to access the file 222 and 111 just create?  ya i dont think that'll work.

you're right, there is no way for this to be done on the data mover side.

i tried that, -o anon=0 option and that didn't work either.  and no, im not having all my users log authenticate as root on my system.

doesn't seem like this is possible for nfsv3 or nfsv4 am i correct?

im sorry, i know the difference between the control station and data mover...

can someone please provide me with a known solution for this giant paperweight i have in my server room?  this cannot be the limitation of nfs for celerra?

If you want uid 222 with gid 111 to have full access (rwx) to any file created by uid 333 with gid 111 then you need to set the umask variable on the Unix server (where uid 222 works)

I see no way to do that from the data mover side

If you want anyone access to any file created by any user, you could export the file system with '-o anon=0' (from CLI) and have all you users authenticating as 'root'

Also, make sure you do not confuse the Control Station (which is being used to administer the NAS) and the data mover (which provides NFS access)

Claude