Bug 136592

Summary: "Mount to NFS server ' **** ' failed: server is down." : Solution???
Product: [Fedora] Fedora Reporter: R.H. Ruskin <swbobcat>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-01 14:27:52 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description R.H. Ruskin 2004-10-20 23:46:57 EDT
Description of problem: NFS problems. I am trying to mount a file
located on the machine "lion". The directory is /cheetah. The NFS
compunets located on both "bobcat" and "lion" are running. I have no
problem mounting /cheetah from "jaguar". The command is mount
lion:/cheetah /cheetah. From "jaguar" a df shows that /cheetah has
been mounted and can be read. When I issue the same command from
"bobcat" I get the following message:
       
        "mount to NFS server 'lion' failed: server is down."

Yet if I issue the command "mount zuni:/sgi /cheetah" which is located
on a remote server, not only does /cheetah mount -- as can be seen
when I issue a df command -- but all the files casn be broused both
from my end as well as from the remote server end.




Version-Release number of selected component (if applicable):

Fedora Core 2 /64


How reproducible:

Every time.

Steps to Reproduce:
1. From "jaguar": mount lion:/cheetah /cheetah
2. From "bobcat": mount lion:/cheetah /cheetah
3.
  
Actual results:
?cheetah mounts from "jaguar" but not from "bobcat"

Expected results:

lion:/cheetah *should* mount from "bobcat".


Additional info:

I can ping all my machines  ("jaguar", "lion", "bobcat") from any of
the other machines on my network and I can ping remote machines not on
my network from any of the machines on my network.
Comment 1 Steve Dickson 2004-10-21 10:19:15 EDT
Could you post an ethereal trace of this? Also
what does mount -v show as far as the RPC error?
Comment 2 R.H. Ruskin 2004-10-21 14:42:57 EDT
Results of Etheral trace:

I pinged lion (from "bobcat") then stared the trace. Here is what I got:
I ran the trace for ~ 2 minutes most of the Protocols listed are ICMP.
The source/ request shows up as 192.168.1.4 ("bobcat") and the
Distination shows as 192.168.1.2 ("lion"). The source / reply shows as
192.168.1.2 ("lion") and the destination as 192.168.1.4 ("bobcat"). I
have two other protocols that show up every once in a while: one
protocol is marked NTP marked 192.168.1.6 ("jaguar" [the third
computer on my network]) and goes to 128.196.128.234 (off my network).
The third protocol is marked ARP.

Below that I get the following message:

> Frame 1 (98 bytes on wire, 98 bytes captured)
> Ethernet II, Scr: 00:20:18:56:df:5f , Dst: 00:50:ba:ee:bc:d6
> Internet Protocol, Scr. Addr: 192.168.1.4 (192.168.1.4) , Dst Addr:
192.168.1.2 (192.168.1.2)
> Internet Control Message Protocol

Results of mount -v:
[root@bobcat/home/rhr]/> mount -v
/dev/hde3 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/hde2 on /backup type reiserfs (rw)
none on /dev/shm type tmpfs (rw)
/dev/hde5 on /home type ext3 (rw)
/dev/hde1 on /tmp type ext3 (rw)
/dev/hde7 on /var type ext3 (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)


 
Comment 3 Steve Dickson 2004-10-21 15:12:24 EDT
what is the output of rpcinfo -p lion 
Comment 4 R.H. Ruskin 2004-10-23 17:20:43 EDT
[root@bobcat/home/rhr/update]/> /usr/sbin/rpcinfo -p lion
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100011    1   udp    637  rquotad
    100011    2   udp    637  rquotad
    100005    1   udp   1025  mountd
    100005    1   tcp   1024  mountd
    100005    2   udp   1025  mountd
    100005    2   tcp   1024  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100021    1   udp   1026  nlockmgr
    100021    3   udp   1026  nlockmgr
    100021    4   udp   1026  nlockmgr
    100021    1   tcp   1025  nlockmgr
    100021    3   tcp   1025  nlockmgr
    100021    4   tcp   1025  nlockmgr
    100024    1   udp    686  status
    100024    1   tcp    688  status
Comment 5 R.H. Ruskin 2004-10-24 08:00:50 EDT
Want to pass this on, my buddy found this command somewhere on the net
and it works.

Thanks for your interest in my problem. Hoope this will help others
who may be facing the same problem as I.

            mount -o nfsvers=2 lion:/cheetah /cheetah
Comment 6 Steve Dickson 2004-11-02 14:49:14 EST
The mountd on lion should be logging some reason
(in /var/log/messages) as to why its not allowing 
mounts from cheetah....
Comment 7 Robert Buffington 2005-03-31 17:23:59 EST
This should now be moved to Fedora Core (fc3) as of Mar 31 because apparently 
a yum update, perhaps util-linux-2.12a-21, broke NFS mounts from our Linux 
RHL9-legacy (nfs-utils-1.0.1-3.9) server. No other changes to our NFS server 
were made, and other same-level Linux systems can still mount filesystems with 
no problems from the server. Using nfsvers=2 seems to have no effect for me.

There also seem to be no messages logged (as mentioned in comment #6) in our 
server's /var/log/messages.

# mount -v /var/spool/mail
mount to NFS server 'hostx' failed: server is down.
RPC Error: 0 ( Success )

# mount -t nfs -o nfsvers=2 hostx:/opt/net/mail /var/spool/mail
mount to NFS server 'hostx' failed: server is down.
Comment 8 Steve Dickson 2005-03-31 21:41:27 EST
I believe this is duplication of bz152956. Would you mind
trying the util-linux that is in http://people.redhat.com/steved/bz152956
to see if it fixes the problem
Comment 9 Robert Buffington 2005-04-01 14:25:17 EST
Yes - this worked. And you're right, this one should be marked as a duplicate 
of 152956. This is in fact a util-linux problem and has nothing to do with nfs-
utils, even though it's NFS-related. Thanks for your reply!

Comment 10 Steve Dickson 2005-04-01 14:27:52 EST

*** This bug has been marked as a duplicate of 152956 ***