Problem with NFS server Time Out

[Joyjeet]

Sponsored Links

hi there.

I have a NFS server which runs with the help of Free BSD and my clients are running with Linux operating system. The problem starts here and goes mysterious as NFS shows a problem of server timed outs.

As I mount Free BSD's NFS try to share my Linux client and everything works fine, but after sometime NFS totally freezes. And If I am trying to transfer data from server, it never tries to freeze.

This is so called mysterious because Free BSD server still responds to Free BSD clients.

[Zachary]

Have you checked with netstat? nfsstat? Can you run
sar so that you could get a better picture of what is
going on on each end of the transfer? Can you watch
'top' on the server-side while transfers take place?

Is your nfs mount 'soft' or 'hard', with or without 'intr'?

[Big Fish]

Restart your NFS server:
sudo /etc/init.d/nfs-kernel-server restart

Now open your syslog and look for any NFS server messages:
less /var/log/syslog | grep -i nfs

Let us know what you find. Chances are something's not right in your /etc/exports file. It'd be great if you could post that as well.

[Shen]

I thought I had finally gotten that sorted out, since it SEEMED to be working (I saw all the server's users listed in the client's login window) but the NIS server itself was actually not in it's own /etc/ypserv.securenets file, so was not able to bind to itself, even though it was successfully starting services and offering them to the client, who _was_ defined in the file. I added the actual NIS server's IP address to the list, restarted NIS

[Steve123]

You can ctrl/C the cp -r or tar and it will eventually return to the shell prompt.
If you then umount and mount with rsize=1024,wsize=1024, it will work fine.

The customer says this all started when he installed 101318-59 on the SS20
He had a 3rd party network co-processor board (nc0 and nc1) and everything
was fine at 101318-50. He installed 101318-59 for the utmp fixes and this
problem started.

He disabled the network co-processor board and is now using on-board ethernets
and still has the problem.

He tried backing out 101318-59 and running 101318-50 and still had the problem.
He is running 101318-59 now.

So, the problem seems to have appeared at the same time he installed 101318-59
but perhaps that is only a coincidence.

The snoop trace can be found on

/net/jedi.east/export/home/pub/SO#1845195