Solved

NFS Connection refused

Posted on 2011-09-26
14
1,896 Views
Last Modified: 2013-12-15
Hi, experts.
I am having problem mounting my nfs mount on my sles11.
NFSSERVER IS RUNNING:
rcnfsserver status
Checking for kernel based NFS server: idmapd..running
 mountd..running
 statd..running
 nfsd..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
 mountd..unused
 statd..running
 nfsd..running
There are no
/etc/hosts.allow and /etc/hosts.deny
Can somebody help me.
Sorry my english.

0
Comment
Question by:edolivier
  • 6
  • 4
  • 3
  • +1
14 Comments
 
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
0
 
LVL 4

Expert Comment

by:klodefactor
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 0.0.0.0:2049                0.0.0.0:*                   LISTEN      -
tcp        0      0 0.0.0.0:51204               0.0.0.0:*                   LISTEN      2003/rpc.statd
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      1984/portmap
tcp        0      0 0.0.0.0:733                 0.0.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.

--klodefactor
0
 
LVL 5

Expert Comment

by:hossamshaaban
ID: 36708374
check the connection between NFS client and NFS server and check the ports 111/udp and 2049/tcp are opened.
0
 

Author Comment

by:edolivier
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)

0
 

Author Comment

by:edolivier
ID: 36709896
checking the connection between client and server
nmap server
Starting Nmap 4.75 ( http://nmap.org ) at 2011-09-27 10:39 BRT
Interesting ports on server (172.168.0.8):
Not shown: 995 closed ports
PORT     STATE SERVICE
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
0
 
LVL 5

Expert Comment

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

Author Comment

by:edolivier
ID: 36711090
telnet worked

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

on server
server:/etc # tcpdump -i br0 -n host 172.168.0.8
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 172.168.0.9.979 > 172.168.0.8.111: UDP, length 56
11:50:51.404479 IP 172.168.0.8.111 > 172.168.0.9.979: UDP, length 28
11:50:51.405202 IP 172.168.0.9.979 > 172.168.0.8.56493: S 3864516271:3864516271(0) win 5840 <mss 1460,sackOK,timestamp 86267177 0,nop,wscale 7>
11:50:51.405216 IP 172.168.0.8.56493 > 172.168.0.9.979: R 0:0(0) ack 3864516272 win 0
11:50:51.405518 IP 172.168.0.9.979 > 172.168.0.8.111: UDP, length 56
11:50:51.405560 IP 172.168.0.8.111 > 172.168.0.9.979: UDP, length 28
11:50:51.405757 IP 172.168.0.9.979 > 172.168.0.8.39672: UDP, length 72
11:50:51.405773 IP 172.168.0.8 > 172.168.0.9: ICMP 10.85.0.34 udp port 39672 unreachable, length 108
11:50:56.400510 arp who-has 172.168.0.9 tell 172.168.0.8
11:50:56.400607 arp reply 172.168.0.9 is-at 00:21:5e:db:9d:98
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel



0
Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 5

Expert Comment

by:hossamshaaban
ID: 36712184
telnet check only TCP ports not UDP
0
 
LVL 4

Expert Comment

by:klodefactor
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).

--klodefactor
0
 

Author Comment

by:edolivier
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.
0
 
LVL 4

Expert Comment

by:klodefactor
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.

--klodefactor
0
 

Author Comment

by:edolivier
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.
0
 
LVL 4

Accepted Solution

by:
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+ (http://www.memtest.org/).  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 :-)
--klodefactor
0
 

Author Closing Comment

by:edolivier
ID: 36730088
Thank you !
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
oracle query help 36 67
VMWare 6 crashing 14 56
Parse DNS log 3 33
Java / Linux and Regular Expressions 11 47
Introduction We as admins face situation where we need to redirect websites to another. This may be required as a part of an upgrade keeping the old URL but website should be served from new URL. This document would brief you on different ways ca…
​Being a Managed Services Provider (MSP) has presented you  with challenges in the past— and by meeting those challenges you’ve reaped the rewards of success.  In 2014, challenges and rewards remain; but as the Internet and business environment evol…
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

757 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now