Bug 131995 - [nfs] Failure to mount NFSv4 server
Summary: [nfs] Failure to mount NFSv4 server
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Jaakko Heinonen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-23 05:20 UTC by Jeff Garzik
Modified: 2010-06-17 20:15 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Garzik 2009-02-23 05:20:01 UTC
I am the author of an NFSv4 userland server.  Linux and OpenSolaris NFSv4 clients successfully talk to my server, but FreeBSD 7.1 does not.

Problems observed:

1) The "-4" argument to mount_nfs does not automatically set the TCP (-T) and port 2049 (-o port=2049) options.  These are the defaults for NFSv4.  Quoting RFC3530:

   The registered port 2049 [RFC3232] for the NFS protocol
   should be the default configuration.  Using the registered port for
   NFS services means the NFS client will not need to use the RPC
   binding protocols as described in [RFC1833]

2) As quoted above in RFC3530, rpc bind/mount protocols are not needed for NFSv4, and should not be required to mount an NFSv4 filesystem.

3) When supplying the '-4', '-T' and -'o port=2049' options, FreeBSD's NFSv4 client successfully contacts my server... and tries to speak NFSv3!  RPC header from
     mount_nfs -4 -T -o port=2049 bd:/ /bd
yields
          RPC version: 2
          RPC program: 100003
          RPC program version: 3

FreeBSD 7.1 also has problems mounting a known-working-with-multiple-clients Linux NFSv4 server, but I'll leave that for a separate bug report.

Fix: 

1. Directly connect to port 2049 over TCP by default, for NFSv4.  No need to consult portmapper, rpcbind, mountd, etc.

2. Actually speak NFSv4 RPC protocol, once connected to an NFSv4 server (see problem #3, above).
How-To-Repeat: 1. Install Linux
2. Install my NFSv4 server from git repository: http://linux.yyz.us/projects/nfsv4.html
3. Run my NFSv4 server under Linux (sorry, no fBSD support... yet).
4. Run tcpdump on client or server, watching the NFS and RPC traffic
5. Attempt to mount Linux NFSv4 userland server from FreeBSD NFSv4 client
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-02-23 08:49:12 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Ed Schouten freebsd_committer freebsd_triage 2009-09-18 14:41:51 UTC
Responsible Changed
From-To: freebsd-fs->rmacklem
Comment 3 Ed Schouten freebsd_committer freebsd_triage 2009-09-18 14:42:28 UTC
Responsible Changed
From-To: rmacklem->freebsd-fs

Woops! Better put it back on fs@. 

It looks like this has something to do with the old NFS implementation.
Comment 4 Jaakko Heinonen freebsd_committer freebsd_triage 2010-03-10 16:03:11 UTC
State Changed
From-To: open->feedback

University of Michigan NFSv4 client has been removed from head and stable/8. 
A new, experimental implementation with support for NFSv4 is available in 
head and stable/8. 

Can you still reproduce the problems with the new implementation? The file 
system type for mount(8) command is newnfs. 


Comment 5 Jaakko Heinonen freebsd_committer freebsd_triage 2010-03-10 16:03:11 UTC
Responsible Changed
From-To: freebsd-fs->jh

Track.
Comment 6 Jaakko Heinonen freebsd_committer freebsd_triage 2010-06-17 20:15:09 UTC
State Changed
From-To: feedback->closed

Feedback timeout.