NFS & IGNITE Problem

[likid0]

Hy,
I have a machine, that has started to have problems with the make_net_recovery against the ignite servers, the error it gives is:

make_net_recovery -s epsilon
* Creating NFS mount directories for configuration files.

======= 04/11/07 13:55:29 METDST Started make_net_recovery. (Wed Apr 11
13:55:29 METDST 2007)
@(#)Ignite-UX Revision C.6.9.150
@(#)ignite/net_recovery (opt) $Revision: 10.834 $ $Date: 2006/06/14
13:47:40 $

* Testing for necessary pax patch.
* Passed pax tests.
* Checking Versions of Recovery Tools
* Creating System Configuration.
WARNING: The volume group /dev/vg00 will be only partially included in the
System Recovery Archive. This means that not all files and
directories on this volume group will be restored when the archive is
installed. This message can be suppressed using the "-P s" option for
make_net_recovery. See make_net_recovery(1M) for more details.

* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
0306E0E372A/recovery/2007-04-11,13:55/system_cfg vg00
NFS server epsilon not responding still trying
NFS server epsilon not responding still trying
NFS server epsilon not responding still trying
NFS server epsilon not responding still trying
NFS server epsilon not responding still trying
NFS server epsilon not responding still trying

this happens againts 3 ignite servers, the 3 of the give the same error, both client and server have the same version C.6.9.150


this is what i have tried out allready:

in the client:
restart nfs
reinstall ignite client
check lan speed: 1000auto the same as the servers
reboot the server ...
mounting nfs by hand and lauching save_config -f by hand it gives the same error

on the server:
restart nfs
rm the client conf 0x0etc, so it generates it again
rpinfo -p
showmount -e look ok
tcmpdumping on the server i get very little nfs trafic from the client:

eps:/# /usr/local/sbin/tcpdump -c 200 src host 10.132.5.91
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lan0, link-type EN10MB (Ethernet), capture size 68 bytes
14:22:30.202137 IP eps.org..722376 > eps.org.e.nfs: 140 getattr [|n fs]
14:22:30.220870 IP eps.org..722377 > eps.org.nfs: 140 getattr [|n fs]
14:22:30.221019 IP eps.org..722378 > eps.org nfs: 140 getattr [|n
the application that runs in the box works fine, it has to be a client nfs issue but i have no ideas, any help???

THNX!

[Steven E. Protter]

Shalom,

I still suspect networking.

Other things to check.

Hardware (cstm/mstm/xstm) the NIC card.
Network hardware.
Patching (Bi-annual, special nfs patches)

Permissions on the NFS share.

/etc/exports parameters limiting host access.

SEP

[Andrew Scott_3]

I'm having this exact same problem with Ignite after upgrading the Ignite server from 11iV2 to 11iV3. My clients can no longer mount NFS shares on the Ignite server.

Even attempting to mount NFS shares from the command line from the clients gives me the "NFS server not responding still trying"

The server logs a single message in syslog.log when a mount request is initiated:

"vmunix: WARNING: nfsauth: mountd not responding"

I have NFS_TCP=1 and MOUNTD_OPTIONS="-o proto=tcp" set on both sides of the equation. Both machines can ping and ssh to each other. Before the 11iV3 upgrade on the server, nfs worked fine. I'm stuck.