bismark@alta.Jpl.Nasa.Gov (Bismark Espinoza),
David Warren <warren@atmos.washington.edu>,
John Stoffel <jfs@fluent.com>, and
Knut.Hellebo@nho.hydro.com,
all of whom run Alpha boxes with nfsportmon off and have no trouble
mounting from a Solaris box. I did not hear from anyone who
successfully mounts from an Alpha box that runs with nfsportmon on, so
at least for now the conclusion must be that IT CANNOT BE DONE.
My original message is here:
I have a curious NFS problem. I've looked at times for the answer to
this one in this list and in other lists, but haven't found it.
We're trying to NFS-mount a filesystem exported by a DEC Alpha running
Digital UNIX V3.2D-1 (aka OSF1 V3.2) on a SPARC runnning Solaris
2.5.1. (The OSF1 system allows mounts only from secure ports, and the
Solaris system has NFS parameters portmon and shrinkreaddir turned
on.) Result is:
# mount alphabox:/g3 /mnt
nfs mount: alphabox: NFS service not responding
nfs mount: retrying: /mnt
(Or if the automounter is trying it, "No such file or directory.")
Other brands of UNIX we run have no trouble with this, e.g. IRIX
[56].x, AIX 3.2.5, SunOS 4.1.x, Linux [12].x all can export to/mount
from Solaris systems. Also, the other brands have no problem mounting
from OSF1 systems.
I could be off-base here, but in looking at snoop traces, the basic
difference between Solaris and the others seems to be that Solaris
uses an unsecure source port (>1024) for its initial RPC Null
Procedure call to the NFS destination port. As clients, other flavors
of UNIX use a secure source port for NULL calls, and as servers they
accept NULL calls on unsecure ports. Once Solaris notes the NULL
procedure has succeeded (on Non-OSF1 systems), it then uses a secure
port for the "real" NFS procedure calls. OSF1 is the only flavor of
UNIX that is bothered by this behavior: it rejects the original NULL
procedure and Solaris then apparently assumes that the OSF1 server is
temporarily not responding to its NFS client requests, e.g. here's
OSF1's response to the NULL proc (from the relevant part of a snoop
trace):
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 2049
UDP: Destination port = 62705 (Sun RPC)
UDP: Length = 28
UDP: Checksum = 1BA4
UDP:
RPC: ----- SUN RPC Header -----
RPC:
RPC: Transaction id = 860467039
RPC: Type = 1 (Reply)
RPC: This is a reply to frame 3
RPC: Status = 1 (Denied)
RPC: Reject status = 1 (can't authenticate)
RPC: Why = 5 (too weak)
While this behavior doesn't seem to violate (my reading of) the letter
of the NFS specs, it certainly violates the spirit.
Anyone have a solution? Some way to make SOlaris use a secure port
for NULL procedure calls, perhaps?
The administrator of the OSF1 system adamantly refuses to allow
unsecure ports to initiate mount requests, so that's not an option.
Warren Jessop
University of Washington Computer Science and Engineering.