NFS Help

Me again! (Haven’t yet followed up with the last post.)

One of the fun things I have ran into with Solaris->ONTAP is that if you do not have Kerberos configured (default!) and do the basic “mount foohost:/barpath /bar”, Solaris mounts with NFSv4. Since you don’t have Kerberos setup, you get read-only permissions no matter what you do.

Telling Solaris to use NFSv3 fixes the issue completely. Now, I’m commenting from a Mac but I don’t have it on the same subnet as my filer, so I can’t test to see if this issue is present under OS X as well as Solaris.

Hope this helps,

A.

What version of ONTAP are you running? Here’s a line from our 8xx series:

/vol/vol1 -sec=sys,ro=10.250.38.0/24,rw=10.250.38.5,root=10.250.38.5,nosuid

Substitute the 10.250.38.5 with your mac IP. Try this with and without the root=xxx clause.

Also do a “showmount -e $filer_ip” from your mac and see what gets returned.

Why don’t you show us the line from /exports for the share. Also are you using the finder to do the mount or the command line. Try the command line if you used the finder and show the command here. A showmount -e as jimmy says would be good.

Paste the exports line as suggested above…. but also, make your client use NFSv3 to make troubleshooting easier. Paste the output of “mount” so we can see if it got mounted read-only or got mounted read-write but doesn’t allow you to write. On top of things, if you are root, root has special permissions and you need to make sure root squash is not off. If it is, root becomes the user nobody or nobody4 depending on your OS.

Snapmirror is the bomb by the way. Oh, and Netapp is the bomb too.

Sorry, that should be make sure root squash is not on. (but read the security implications first). Also, forgot to mention if you change permission stuff, you should exportfs -f from the filer to make sure the acl’s get flushed. I always use command line for the Netapp stuff, not sure if the GUI has a -f option for re-exporting.

an addendum to my previous post: we’re running nfs.v3 over tcp. God bless brotha.

Given that you have sec=sys Kerberos is not in the picture. They are sec=krb5 etc.

Are you sure the requests are coming from the ip address you think they are, has it got more than one interface etc ?

What does showmount -e give.

What does trying the mount from the command line do.

Try setting option nfs.mountd.trace on and examine /etc/messages.

What does exportfs -c 10.16.2.149 /vol/fvol_vmdata rw sys

If you can mount the volume, it’s likely not the export line. I’d bet its simply “non-matching” UIDs, aka a permission problem. The export is with “sys” security (the default), which means standard UNIX permissions are in effect. So the client says “I’m uid=500″ and the server trusts that, and checks to see if that uid has permission on the local filesystem. So you have to matchup UIDs on both sides. My guess is that the directory you’re trying to write to isn’t owned by the UID of your account on the MBP.

As root on the MBP chown the directory on the exported volume to your OS X uid, and you’ll be in business.

Also, drop the “ro” option from your export. “ro” and “rw” next to each other is confusing.

showmount -e showing an error is interesting

The exportfs -c 10.16.2.149 /vol/fvol_vmdata rw sys should show the effective permissions.

From a random manual as I am at home and away from my filer and I haven’t brought a simulator up on my mac.

“-c
Checks whether an NFS client has a specific type of access to a file system path. You must specify the IP address of the NFS client (hostip) and the exported (not actual) file system path (path). To check whether the NFS client has read-only, read-write, or root access to the file system path, specify the ro, rw, or root option, respectively. If you do not specify an access type, Data ONTAP simply checks whether the NFS client can mount the file system path. If you specify an access type, you can also specify the NFS client’s security type: sys, none, krb5, krb5i, or krb5p. If you do not specify a security type, Data ONTAP assumes the NFS client’s security type is sys. Note: If Data ONTAP does not find an entry in the access cache corresponding to (1) the file system path and (2) the NFS client’s IP address, access type, and security type, Data ONTAP (1) determines the NFS client’s host name from its IP address (for example, it performs a reverse DNS lookup), (2) checks the NFS client’s host name, access type, and security type against the file system path’s export options, and (3) adds the result to the access cache as a new entry.”

To become root on a mac do the following as a admin user

simonsmachine:/Users/jb3134 dirk$ sudo bash
Password:
simonsmachine:/Users/jb3134 root#

you can use su to go from non admin to admin user.

The question here is is the filesystem being mounted read/write or do you not have permission to write the files ?

the root= just says not to map the root user to nobody, so you can do privileged operation over nfs. The account doing the operation still needs permission to do the operation. So the first question is is the mount read-write or read-only ?

Scott,

It not that the root account isn’t enabled you just need to jump though hoops to run processes as root.

ps -auxww | grep root |wc -l

Will show a number of processes running as root, 52 on my mac as this instant.

>> OK, here’s the /etc/exports line that is currently in effect:
>> /vol/fvol_vmdata -sec=sys,ro,rw=10.16.2.149,root=10.16.2.149

try this:
/vol/fvol_vmdata -sec=sys,rw=10.16.2.149,root=10.16.2.149,ro

Best regards.

Another note:
NFS is the best you can get for VMware datastores.
Tons of benefits, and almost no cons (Especially with WAFL from NetApp of ZFS from SUN).
For example see this discussion thread:
http://www.vmware.com/community/thread.jspa?threadID=51698&start=0&tstart=0

best regards.

Another thing to try:
/vol/fvol_vmdata -sec=sys,rw=10.16.2.149,root=10.16.2.149,ro,anon=0

best regards.

Scott I have this exact problem with my MB Pro and our new netapp and my DataONTAP sim. did you every find a solution for this problem?

its drivin me nuts..

thanks,

Great thanks Scott,

i did a qtree from the command line and my volume /vol/mrkt is set to unix. also can you tell me how you mounted the nfs volume on your mb, command, Finder, etc..

Thanks,

ScottMcD

I found that when I looked at my qtree as well and changed it to unix, that the same problem you had described above resolved itself.

I think with your MAC, you have to either do the work as root which is a common uid of 1 and ensure that root=mac’s ip, you need a common set of uid/gid to do the work on these net apps

The exportfs -c really helped me, it returned the following (note, this is when my qtree was set to mixed)

mofs011> exportfs -c 172.xxx.xxx.xxx /vol/hds rw sys
exportfs: 172.xxx.xxx.xxx does not have rw access to /vol/hds (No access cache entry, try again)
exportfs: 172.xxx.xxx.xxx has rw access to /vol/hds
mofs011> exportfs -c 172.xxx.xxx.xxx /vol/hds root sys
exportfs: 172.xxx.xxx.xxx does not have root access to /vol/hds (No access cache entry, try again)
exportfs: 172.xxx.xxx.xxx has root access to /vol/hds

I reran it again now and I get:
exportfs: 172.xxx.xxx.xxx has root access to /vol/hds

I did everything except looking at the Qtree type. This Blog directed me in the Proper direction. What a fool I was!!!

Thanks a million