NFS Connection refused

Hi, experts.
I am having problem mounting my nfs mount on my sles11.
rcnfsserver status
Checking for kernel based NFS server: idmapd..running
when I try to mount server:/xen  /client_files
mount.nfs: mount to NFS server 'server:/xen' failed: System Error: Connection refused
when I run rcnfsserver status on the server again
Checking for kernel based NFS server: idmapd..running
There are no
/etc/hosts.allow and /etc/hosts.deny
Can somebody help me.
Sorry my english.

Who is Participating?
klodefactorConnect With a Mentor Commented:
Holy mackerel.

The first thing I'd do is apply all OS updates and try again.  I assume of course that this isn't a strictly controlled production environment that can't be updated...

I just noticed that *mountd* is dying, not the NFS daemon.  Sorry for the confusion.  The mountd problem appears to have existed at some point in RedHat too, although it was several years ago.  If you can't apply OS updates, or if you apply them and it doesn't help, you could review the contents of /etc/nsswitch.conf and remove any references to "nis" and "nisplus" if you're not using them in your environment.

Low priority: if none of the above helps, you may want to try Memtest86+ (  It's unlikely that only the mount daemon would die, but if you've seen other odd behaviour this is an easy sanity check.

(fingers crossed :-)
Gary DavisDir Internet SvcsCommented:
Connection Refused means that the attempt to connect to the port on the server is failing because nothing is listening on that port. It usually means the process is not running but it could mean that the wrong port is used.

It could also be that the server is wrong, of course. Also, things could block the port like a firewall but I don't know if that would result in a Connection Refused. That message means your request reached the server (or some server) but the port is not bound.

Gary Davis
What is the contents of  /etc/exports?  Assuming you haven't rebooted, did you remember to run exportfs -av?

Is portmap running?  What does rpcinfo -p report?  You should see something like:
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  32768  status
    100024    1   tcp  51204  status
    100003    4   udp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    4   udp  32794  nlockmgr
    100021    4   tcp  45440  nlockmgr
    100005    3   udp    730  mountd
    100005    3   tcp    733  mountd

Open in new window

You can check which ports have listeners (and which process is doing the listening) with netstat -lanp:
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0      *                   LISTEN      -
tcp        0      0     *                   LISTEN      2003/rpc.statd
tcp        0      0       *                   LISTEN      1984/portmap
tcp        0      0       *                   LISTEN      2252/rpc.mountd

Open in new window

NFS servers typically listen on TCP/2049 (but check the output of rpcinfo).  Kernel-based NFS wont' show a process ID or process name.

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

check the connection between NFS client and NFS server and check the ports 111/udp and 2049/tcp are opened.
edolivierAuthor Commented:
Thanks for the quick responses.

rpcinfo -p
  program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  40121  status
    100024    1   tcp  54262  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   tcp  45633  nlockmgr
    100021    3   tcp  45633  nlockmgr
    100021    4   tcp  45633  nlockmgr
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  48174  nlockmgr
    100021    3   udp  48174  nlockmgr
    100021    4   udp  48174  nlockmgr
    100005    1   udp  39672  mountd
    100005    1   tcp  56493  mountd
    100005    2   udp  39672  mountd
    100005    2   tcp  56493  mountd
    100005    3   udp  39672  mountd
    100005    3   tcp  56493  mountd

exportfs -av
exporting *:/xen

cat  /etc/exports
/xen      *(rw,nohide,sync,insecure,no_root_squash,no_subtree_check)

edolivierAuthor Commented:
checking the connection between client and server
nmap server
Starting Nmap 4.75 ( ) at 2011-09-27 10:39 BRT
Interesting ports on server (
Not shown: 995 closed ports
22/tcp   open  ssh
111/tcp  open  rpcbind
2049/tcp open  nfs
5801/tcp open  vnc-http-1
5901/tcp open  vnc-1
MAC Address: 00:21:5E:DB:B5:A0

Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds
you need to see the 111/udp also for portmapper.
edolivierAuthor Commented:
telnet worked

client:/ # telnet server 111
Connected to server.
Escape character is '^]'.
on client
showmount server

on server
server:/etc # tcpdump -i br0 -n host
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes

11:50:51.404366 IP > UDP, length 56
11:50:51.404479 IP > UDP, length 28
11:50:51.405202 IP > S 3864516271:3864516271(0) win 5840 <mss 1460,sackOK,timestamp 86267177 0,nop,wscale 7>
11:50:51.405216 IP > R 0:0(0) ack 3864516272 win 0
11:50:51.405518 IP > UDP, length 56
11:50:51.405560 IP > UDP, length 28
11:50:51.405757 IP > UDP, length 72
11:50:51.405773 IP > ICMP udp port 39672 unreachable, length 108
11:50:56.400510 arp who-has tell
11:50:56.400607 arp reply is-at 00:21:5e:db:9d:98
14 packets captured
14 packets received by filter
0 packets dropped by kernel

telnet check only TCP ports not UDP
hossamshaaban: yep, but his tcpdump session shows incoming UDP from the client and and outbound UDP response from the server.  So it's probably not the Linux firewall.

edolivier: I'm convinced your firewall isn't this issue but if you really want to poke at this you could always shut down NFS on the server and run netcat ("nc") on the server, listening on UDP/2049:
nc -ul 2049

Open in new window

Then run netcat from the client and point to the netcat on the server:
nc -u SERVERNAMEorIP 2049

Open in new window

Then type something like "hello"<ENTER> on the client.  You should see "hello" appear on the server beneath the listening netcat command.

The puzzling bit is the "connection refused" message, which would normally indicate that nothing on the server is listening on that port.  Hmm...have you started the NFS server then just waited 5-10 minutes without trying to connect from the client?  Maybe what's happening is:
- start NFS daemon on server
- check NFS daemon status OK
- NFS daemon dies
- try to connect from client and get "connection refused"
Have you checked your kernel logs (dmesg or somewhere in /var/log depending on your Linux distribution) and NFS logs (possibly /var/log/messages)?

Have you tried mounting the NFS share on the server itself?  E.g.:
servername# mkdir /mnt/tmpspot
servername# mount servername:/xen /mnt/tmpspot

Open in new window

After the test, don't forget to rmdir /mnt/tmpspot (possibly after a umount /mnt/tmpspot).

edolivierAuthor Commented:
Tomorrow I will test netcat. But, as I had stated previously, I would like someone to tell me why when I run this command:  mount server:/xen  /client_files, in the client, the daemon mountd  is in the unused state.
he was before the mount command in the state of running
 mountd..running (the server)  ->  mount command (the client)  ->   mountd..unused (on server)
nobody said this, I want you expert comment for this transition from running unused.
Sorry my english.
Thank you all.
No problem with your english, we'll get this problem sorted out together :-).

I only suggested netcat in case you were concerned that you have firewall  problems.  Myself, I don't think it's the firewall so I wouldn't bother with the test at this point.

In that same post I suggested one possibility: that the NFS daemon dies before you try to mount from the client.  Of course it could be dying *because* you try to mount from the client, but that would be a serious bug.  Anyway that's why I suggested you check your kernel logs and NFS daemon logs, to see whether there's a record of the daemon dying.

edolivierAuthor Commented:
Thanks klodefactor.
Certainly the daemon is dying *because* I try to mount.  This is the  log:
Sep 28 19:00:04 vs0 kernel: rpc.mountd[10790]: segfault at fffffffe80000017 ip 00007f7249518c18 sp 00007fff51525c60 error 4 in rpc.mountd[7f7249513000+16000]
In a situation like that What should I do.
edolivierAuthor Commented:
Thank you !
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.