NFS Manager

Thanks very much for the response.

I do not fully understand, but I infer from the fact that the subnet text box is grayed out (in NFS Manager, server config) that this only applies to configurations where I am exporting it up to a subnetwork. I'm only trying to export it to a specified IP address. Am I wrong in that inference above? If so, how can I make this subnet modification?

Kris

Thanks again for the response.

I understand what you are saying now. Yes, both client and server already have subnets set to 255.255.254.0. I just verified this.

So there is still a problem of some sort.

Kris

Update: as I mentioned above, running "rpcinfo -p server" on the client shows no programs registerd. However, when I run on the same exact command on the server, it sees itself:

mast:/Users/walker>rpcinfo -p 132.239.152.84

program vers proto port

100000 2 udp 111 portmapper

100000 3 udp 111 portmapper

100000 4 udp 111 portmapper

100000 2 tcp 111 portmapper

100000 3 tcp 111 portmapper

100000 4 tcp 111 portmapper

100024 1 udp 693 status

100011 1 udp 994 rquotad

100011 2 udp 994 rquotad

100024 1 tcp 765 status

100011 1 tcp 761 rquotad

100011 2 tcp 761 rquotad

100021 0 udp 688 nlockmgr

100021 1 udp 688 nlockmgr

100021 3 udp 688 nlockmgr

100021 4 udp 688 nlockmgr

100021 0 tcp 755 nlockmgr

100021 1 tcp 755 nlockmgr

100021 3 tcp 755 nlockmgr

100021 4 tcp 755 nlockmgr

So what am I missing? Hidden Apple firewall? Port blocker somewhere, such as at a router?

Kris

Sorry, I meant "default gateway", not "router". But sounds like there is direct communication without interference from such a middle-person.

Yes, no WiFi is involved. And I can ping the server from the client (and vice versa) just fine. I can also ssh from client to server and vice versa.

I tried to determine if there was a way to ping a specific port, but I wasn't able to find out how to do this.

Thank you,

Kris

I am now diving into the man page of rpcinfo. I have made some progress. To make it easier to follow:

server = mast

client = sail

on server mast, I found the "programs" and port numbers being used:

mast:/Users/walker>rpcinfo -p

program vers proto port

100000 2 udp 111 portmapper

100000 3 udp 111 portmapper

100000 4 udp 111 portmapper

100000 2 tcp 111 portmapper

100000 3 tcp 111 portmapper

100000 4 tcp 111 portmapper

100024 1 udp 693 status

100011 1 udp 994 rquotad

100011 2 udp 994 rquotad

100024 1 tcp 765 status

100011 1 tcp 761 rquotad

100011 2 tcp 761 rquotad

100021 0 udp 688 nlockmgr

100021 1 udp 688 nlockmgr

100021 3 udp 688 nlockmgr

100021 4 udp 688 nlockmgr

100021 0 tcp 755 nlockmgr

100021 1 tcp 755 nlockmgr

100021 3 tcp 755 nlockmgr

100021 4 tcp 755 nlockmgr

on client sail, I use the above information in several rpcinfo calls to learn more:

sail:/Users/walker>rpcinfo -u mast.ucsd.edu 100000

rpcinfo: RPC: Program not registered

program 100000 is not available

sail:/Users/walker>rpcinfo -n 111 -u mast.ucsd.edu 100000

program 100000 version 2 ready and waiting

program 100000 version 3 ready and waiting

program 100000 version 4 ready and waiting

So it would appear that the default port number that is supposed to be resolved by the portmapper on the client side is not actually correct. So I need to force rpcinfo to look at port 111. Is that correct? If so, how do I do this in Disk Utility (I use Disk Utility on client to mount NFS shares)?

Also, I tried TCP:

sail:/Users/walker>rpcinfo -t mast.ucsd.edu 100000

rpcinfo: RPC: Program not registered

program 100000 is not available

sail:/Users/walker>rpcinfo -n 111 -t mast.ucsd.edu 100000

program 100000 version 2 ready and waiting

program 100000 version 3 ready and waiting

program 100000 version 4 ready and waiting

Same port 111. Is that normal? Are several programs all running to use the same port normal?

Thank you,

Kris

You can tell I'm desparate. 🙂

Here is more information. I tried to manually mount the share on the client using mount_nfs specifying the 111 port number that I gleaned from the information in the previous post. But still does not work:

sail.ucsd.edu:/mnt>sudo mount_nfs -o mountport=111 mast.ucsd.edu:/Volumes/L2A/G2S /mnt/test

mount_nfs: can't mount /Volumes/L2A/G2S from mast.ucsd.edu onto /mnt/test: RPC prog. not avail

sail.ucsd.edu:/mnt>sudo mount_nfs -o port=111 mast.ucsd.edu:/Volumes/L2A/G2S /mnt/test

mount_nfs: can't mount /Volumes/L2A/G2S from mast.ucsd.edu onto /mnt/test: RPC prog. not avail

sail.ucsd.edu:/mnt>sudo mount_nfs -o resvport mast.ucsd.edu:/Volumes/L2A/G2S /mnt/test

mount_nfs: can't mount /Volumes/L2A/G2S from mast.ucsd.edu onto /mnt/test: RPC prog. not avail

I did not know which option to use (so tried "mountport", "port", and "resvport").

Any ideas from Apple Networking exports?

Kris

Thanks Grant. I wasn't trying to imply you weren't an "export", just typed too fast.

Kris

Problem identified, but not understood. This sounds like a bug in Lion. Read on if interested.

At face value, it would seem that Apple, in the Lion release, reinterpreted the order of implementation of /etc/hosts.allow and /etc/hosts.deny for the purposes of NFS connections. I have no problem exporting and mounting a folder when I disable the "ALL:ALL" in my /etc/hosts.deny file. Entries in hosts.allow normally take precedence over contents in hosts.deny. It has for many years been this way. But that is not the case, now, for the NFS connection (but it is still the case for the few other wrapped services like sshd). Just to be clear, if I do this:

hosts.deny -

ALL:ALL

hosts.allow -

ALL:ALL

Lion nfsd will *not* export the folder to the client "sail". If I disable both hosts.allow,deny or just disable hosts.deny, then it works.

However...when I specify the client, by hostname, in both the hosts.deny file and hosts.allow file,

hosts.deny -

ALL: sail.ucsd.edu

hosts.allow -

ALL: sail.ucsd.edu

then I *can* also mount the disk. Confused yet? Something else is going on under the hood of Lion that is not apparent. Both client and host have well defined IP addresses visible on the network and registered by the DNS server as verified by "host <hostname>". This problem means that I loose the ability to use tcpwrapping to block out 99.99% of the world while still opening it up to several hundred computers on my local network easily. As far as I can tell, one cannot do the same in the "Sharing" GUI in System Preferences.

My guess is that most people that have NSF Manager working on Lion are not implementing tcpwrapping using hosts.deny, and therefore have not experienced this new problem, which is *not* a problem on Snow Leopard.

Kris