is NetBSD-4.x NFS Server locking support broken?

[Greg A. Woods]

Is NetBSD-4.x NFS Server locking support broken?

(I sure wish NetBSD NFS Client locking worked!)

Since upgrading my Apple laptop to OS X 10.5 I've been having problems
with NFS mounts to my NetBSD-4 server.

The first few times it happened I finally came to suspect locking, after
eventually spotting messages like the following in my system logs:

Sep 19 17:10:17 once rpc.lockd: clntudp_create: RPC: Port mapper failure - RPC: Timed out
Sep 19 17:10:17 once rpc.lockd: Unable to return result to 204.92.254.251
Sep 19 17:10:17 once rpc.lockd: lock from macweird.local.8243: already locked, failed

I've learned to work around the problem with the "nolock" option on OS X:

mount -r -o -P,i,tcp,nolock once:/rest /once/rest

I think I have all the right services running on the NetBSD server:

rpcbind=YES
nfs_server=YES nfsd_flags="-tu -n 4"
mountd=YES
lockd=YES
statd=YES

17:11 [272] $ showmount -a
All mount points on localhost:
ethereal.weird.com:/rest
17:12 [273] $ showmount -e
Exports list on localhost:
/var 204.92.254.0
/rest 204.92.254.0
17:12 [274] $ rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 0 111 portmapper
100000 3 0 111 portmapper
100000 2 0 111 portmapper
100005 1 udp 1021 mountd
100005 3 udp 1021 mountd
100005 1 tcp 1022 mountd
100005 3 tcp 1022 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100001 1 udp 65495 rstatd
100001 2 udp 65495 rstatd
100001 3 udp 65495 rstatd
100002 2 udp 65494 rusersd
100002 3 udp 65494 rusersd
100008 1 udp 65493 walld
100011 1 udp 65492 rquotad
100011 2 udp 65492 rquotad
100024 1 udp 993 status
100024 1 tcp 1010 status
100021 0 udp 992 nlockmgr
100021 1 udp 992 nlockmgr
100021 3 udp 992 nlockmgr
100021 4 udp 992 nlockmgr
100021 0 tcp 1009 nlockmgr
100021 1 tcp 1009 nlockmgr
100021 3 tcp 1009 nlockmgr
100021 4 tcp 1009 nlockmgr


The only thing potentially odd here is that my Macbook is connected
through a NAT (running on my SMC wireless AP).

Can anyone else confirm this?

What more debugging should I try? (next time I reboot the mac I'll try
to remember to try a wired connection to avoid the NAT)

I guess I could try "rpc.lockd -d" too....

[Christos Zoulas]

-=-=-=-=-=-
Is NetBSD-4.x NFS Server locking support broken?
(I sure wish NetBSD NFS Client locking worked!)

somebody wrote the code and posted a patch. We should integrate it.

Since upgrading my Apple laptop to OS X 10.5 I've been having problems
with NFS mounts to my NetBSD-4 server.
The first few times it happened I finally came to suspect locking, after
Sep 19 17:10:17 once rpc.lockd: clntudp_create: RPC: Port mapper failure - RPC: Timed out
Sep 19 17:10:17 once rpc.lockd: Unable to return result to 204.92.254.251
Sep 19 17:10:17 once rpc.lockd: lock from macweird.local.8243: already locked, failed
mount -r -o -P,i,tcp,nolock once:/rest /once/rest
rpcbind=YES
nfs_server=YES nfsd_flags="-tu -n 4"
mountd=YES
lockd=YES
statd=YES
17:11 [272] $ showmount -a
ethereal.weird.com:/rest
17:12 [273] $ showmount -e
/var 204.92.254.0
/rest 204.92.254.0
17:12 [274] $ rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 0 111 portmapper
100000 3 0 111 portmapper
100000 2 0 111 portmapper
100005 1 udp 1021 mountd
100005 3 udp 1021 mountd
100005 1 tcp 1022 mountd
100005 3 tcp 1022 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100001 1 udp 65495 rstatd
100001 2 udp 65495 rstatd
100001 3 udp 65495 rstatd
100002 2 udp 65494 rusersd
100002 3 udp 65494 rusersd
100008 1 udp 65493 walld
100011 1 udp 65492 rquotad
100011 2 udp 65492 rquotad
100024 1 udp 993 status
100024 1 tcp 1010 status
100021 0 udp 992 nlockmgr
100021 1 udp 992 nlockmgr
100021 3 udp 992 nlockmgr
100021 4 udp 992 nlockmgr
100021 0 tcp 1009 nlockmgr
100021 1 tcp 1009 nlockmgr
100021 3 tcp 1009 nlockmgr
100021 4 tcp 1009 nlockmgr
The only thing potentially odd here is that my Macbook is connected
through a NAT (running on my SMC wireless AP).
Can anyone else confirm this?
What more debugging should I try? (next time I reboot the mac I'll try
to remember to try a wired connection to avoid the NAT)
I guess I could try "rpc.lockd -d" too....

Yes... Something seems busted with the locking protocol. I suspect OSX/X.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Greg A. Woods
Is NetBSD-4.x NFS Server locking support broken?

I don't think so.

Post by Greg A. Woods
Since upgrading my Apple laptop to OS X 10.5 I've been having problems
with NFS mounts to my NetBSD-4 server.

It works fine here.

Post by Greg A. Woods
The only thing potentially odd here is that my Macbook is connected
through a NAT (running on my SMC wireless AP).

NAT is evil, especially if RPC is involved.

Kind regards

[Greg A. Woods; Planix, Inc.]

Post by Matthias Scheler

Post by Greg A. Woods
Is NetBSD-4.x NFS Server locking support broken?

I don't think so.

Post by Greg A. Woods
Since upgrading my Apple laptop to OS X 10.5 I've been having
problems
with NFS mounts to my NetBSD-4 server.

It works fine here.

Are you saying you have the same combo of OS X 10.5 and NetBSD-4 and
that NFS mounts with locking enabled and that the locking works in
your configuration?

I just found the following in the NFS Manager app release notes:

"Mac OS X 10.3 uses POSIX advisory file locks to open the address
book database. Some NFS servers are not compatible with the
implementation of NFS locking used by Apple. The lock fails and the
calling applications hangs."

Apparently the Finder uses locking for lots of other stuff too,
including perhaps directory reads based on the kinds of problems I'm
seeing.

Today I also found threads on other mailing lists complaining about
OSX NFS locking causing problems with Solaris NFS servers too, so
perhaps this is partly an OSX problem (i.e. it is trying to use what
it maybe should know is an incompatible locking protocol).

Post by Matthias Scheler

Post by Greg A. Woods
The only thing potentially odd here is that my Macbook is connected
through a NAT (running on my SMC wireless AP).

NAT is evil, especially if RPC is involved.

I'm not sure why that should be -- at least not with a proper NAT
(this isn't ICMP or anything else without port numbers, or even some
bizarre thing like DNS server port randomization). NFS over UDP
works, and that's RPC. It's just the locking that's failing, and it
seems to be the server side that's complaining first it seems, though
I can't yet tell why.

[Manuel Bouyer]

Post by Greg A. Woods; Planix, Inc.
[...]

Post by Matthias Scheler

Post by Greg A. Woods
The only thing potentially odd here is that my Macbook is connected
through a NAT (running on my SMC wireless AP).

NAT is evil, especially if RPC is involved.

I'm not sure why that should be -- at least not with a proper NAT
(this isn't ICMP or anything else without port numbers, or even some
bizarre thing like DNS server port randomization). NFS over UDP
works, and that's RPC. It's just the locking that's failing, and it
seems to be the server side that's complaining first it seems, though
I can't yet tell why.

If your NAT box receive a request on port 111, how should it know to
which client to redirect it ? Not to mention that the NAT box should
also decode RPC replies and install proper port redirection ...

[Matthias Scheler]

Post by Greg A. Woods; Planix, Inc.

Post by Matthias Scheler
It works fine here.

Are you saying you have the same combo of OS X 10.5 and NetBSD-4 and
that NFS mounts with locking enabled and that the locking works in
your configuration?

I'm using ...

NetBSD colwyn.zhadum.org.uk 4.0_STABLE NetBSD 4.0_STABLE (COLWYN) #0: Wed Sep 17 19:26:12 BST 2008 ***@colwyn.zhadum.org.uk:/src/sys/compile/COLWYN i386


... on the server and ...

Darwin excalibur.zhadum.org.uk 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:31:44 PDT 2008; root:xnu-1228.7.58~1/RELEASE_PPC Power Macintosh

... on the client without problems.

If NFS locking wouldn't work Mac OS X would complain violently. It did
that in the past when "rpc.lockd" on my NetBSD server crashed frequently.
But I fixed that bug before NetBSD 4.0 was released.

Kind regards

[Manuel Bouyer]

You says your OS X box is behind a NAT; I wonder is the NAT is
preventing
the server to talk to the client's rpcbind or statd here.

I don't think basic RPC is a problem through the NAT. Note that NFS
over UDP does work fine through the NAT too, and IIRC all of NFS is
RPC too.

Your OS X client is initiating the RPC request to your NetBSD server;
this works. But the NetBSD server has to issue RPC requests to your
OS X client (to contact statd), and I can't see how this one could
work if there's a NAT gateway between the server and the client.

Maybe using RPC over TCP for lockd/statd could help in this case.

How would one do that? Especially since in this case the program
making the requests is effectively the OSX kernel.... (and wouldn't
using NFS over TCP, as I'm doing, do all RCP over TCP?)

I'm not sure, as the lock requests are independant from NFS.

[Edgar Fuß]

somebody wrote the [NFS Locking Client] code and posted a patch.

Oops, I just realized that's two years now!
It's still available as http://www.math.uni-bonn-de/people/ef/nfslock.tar.gz.

We should integrate it.

I would be pleased if you did.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de