NFS Connection refused

Posted on 2011-09-26
Last Modified: 2013-12-15
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.

Question by:edolivier
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 4
  • 3
  • +1
LVL 18

Expert Comment

by:Gary Davis
ID: 36616796
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

Expert Comment

ID: 36620439
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.


Expert Comment

ID: 36708374
check the connection between NFS client and NFS server and check the ports 111/udp and 2049/tcp are opened.
ClickHouse in a General Analytical Workload

We have mentioned ClickHouse in some recent posts, where it showed excellent results.

In this article on Experts Exchange, we’ll look at how ClickHouse performs in a general analytical workload using the star schema benchmark test.


Author Comment

ID: 36709770
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)


Author Comment

ID: 36709896
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

Expert Comment

ID: 36710190
you need to see the 111/udp also for portmapper.

Author Comment

ID: 36711090
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


Expert Comment

ID: 36712184
telnet check only TCP ports not UDP

Expert Comment

ID: 36712535
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).


Author Comment

ID: 36713603
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.

Expert Comment

ID: 36718738
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.


Author Comment

ID: 36720555
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.

Accepted Solution

klodefactor earned 500 total points
ID: 36727310
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 :-)

Author Closing Comment

ID: 36730088
Thank you !

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
Suggested Courses

632 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question