Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


NFS Connection refused

Posted on 2011-09-26
Medium Priority
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.
ATEN's HDBaseT Presentation at InfoComm 2017

Hear ATEN Product Manager YT Liang review HDBaseT technology, highlighting ATEN’s latest solutions as they relate to real-world applications during her presentation at the HDBaseT booth at InfoComm 2017.


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 2000 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

Quick Start: DOCKER

Sometimes you just need a Quick Start on a topic in order to begin using it.. this is just what you need to know to get up and running with Docker!

Question has a verified solution.

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

Using 'screen' for session sharing, The Simple Edition Step 1: user starts session with command: screen Step 2: other user (logged in with same user account) connects with command: screen -x Done. Both users are connected to the same CLI sessio…
SSH (Secure Shell) - Tips and Tricks As you all know SSH(Secure Shell) is a network protocol, which we use to access/transfer files securely between two networked devices. SSH was actually designed as a replacement for insecure protocols that sen…
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
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

661 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