Bug 136592 - "Mount to NFS server ' **** ' failed: server is down." : Solution???
Summary: "Mount to NFS server ' **** ' failed: server is down." : Solution???
Keywords:
Status: CLOSED DUPLICATE of bug 152956
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-21 03:46 UTC by R.H. Ruskin
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-04-01 19:27:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description R.H. Ruskin 2004-10-21 03:46:57 UTC
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 14:19:15 UTC
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 18:42:57 UTC
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 19:12:24 UTC
what is the output of rpcinfo -p lion 

Comment 4 R.H. Ruskin 2004-10-23 21:20:43 UTC
[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 12:00:50 UTC
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 19:49:14 UTC
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 22:23:59 UTC
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-04-01 02:41:27 UTC
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 19:25:17 UTC
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 19:27:52 UTC

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


Note You need to log in before you can comment on or make changes to this bug.