We just installed a new set of Solaris servers, and according to
corporate security standards (don't ask me) they have the
nfssrv:nfs_portmon value set to 1, which requires privileged ports.
We are running the Linux kernel from Red Hat 7.2 (2.4.9-34) on our
clients, using am-utils to mount filesystems from these servers.
This all worked great with the old servers (without nfs_portmon set),
and I can automount the filesystems from the new servers _initially_
just fine (I'm using /net/host/...). However, after the initial timeout
(or sometimes a few timeouts) I start getting these errors on the
client (for any access, not just df, of course):
$ df /net/zbl6s051/export/.
df: `/net/zbl6s051/export/.': Permission denied
Apparently caused by these messages on the server (cause/effect is a
little hard to determine positively):
Jan 24 06:25:35 zbl6s051 nfssrv: [ID 713913 kern.notice] NOTICE: nfs_server: client lemming (47.17.140.90) sent NFS request from unprivileged port
After I get this the only way to recover is unmount the filesystem and
remount it, which is obviously not acceptable.
Some people on the am-utils list seem to think this is more likely
related to NFS than to am-utils, so I'm wondering if anyone here is
familiar with this issue?
The mount parameters am-utils uses when mounting are (from /proc/mounts):
zbl6s051:/export /amd/net/zbl6s051/export nfs rw,nosuid,v3,rsize=8192,wsize=8192,soft,intr,tcp,lock,addr=zbl6s051 0 0
Also, I have a user running Red Hat 8.0 (Linux 2.4.18-14) and (although
I haven't rigorously verified this yet) although they're running the
same version of am-utils they don't appear to be having this problem.
Maybe there was an NFS fix between 2.4.9 and 2.4.18 that relates to
this? Or a flag or parameter that can be set?
Thanks for any/all insight you can provide: we're working on rolling out
a new initiative for Linux on the desktop and getting this working is
crucial to its success...
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 24 Jan 2003 10:04:35 -0500, Paul Smith <[email protected]> wrote:
>
> Also, I have a user running Red Hat 8.0 (Linux 2.4.18-14) and (although
> I haven't rigorously verified this yet) although they're running the
> same version of am-utils they don't appear to be having this problem.
> Maybe there was an NFS fix between 2.4.9 and 2.4.18 that relates to
> this? Or a flag or parameter that can be set?
The addition of these two lines to net/sunrpc/xprt.c:xprt_reconnect(),
somewhere between 2.4.10 and 2.4.18, is probably what fixed it:
if (xprt_connected(xprt))
goto out_write;
+ if (sock && sock->state != SS_UNCONNECTED)
+ xprt_close(xprt);
status = -ENOTCONN;
if (!(inet = xprt->inet)) {
If you can't upgrade the client kernels (2.4.9-34 is no longer the latest
errata kernel for any RedHat version, was replaced by 2.4.18-19.7.x), then
forcing all rh7.x clients to use UDP mounts should cure the problem.
Ion
[am-utils co-maintainer]
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs