Bug 165346 - NFS refuses to export directory - claiming it doesn't exist
Summary: NFS refuses to export directory - claiming it doesn't exist
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-08 13:03 UTC by Adrian McMenamin
Modified: 2008-02-28 09:14 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-02-28 09:14:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Adrian McMenamin 2005-08-08 13:03:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Fedora/1.7.10-1.5.1

Description of problem:
I get messages like this in the message log:

Aug  8 13:51:28 mayday rpc.idmapd: nfsdreopen: Opening '' failed: errno 2 (No such file or directory)

When trying to export like this:

/home/adrian/linux-sh/initrd   192.168.61.55(rw,sync,nohide,no_root_squash,insecure,no_subtree_check,insecure_locks)

The directory does exist:

1817267 drwxrwxr-x   8 adrian adrian     4096 Aug  4 23:09 initrd


When I attempt to mount, as nfsroot, this directory the client (a Sega Dreamcast with a 2.6.12.3 kernel) reports an server error -13 and then a kernel panic as there is no root filesystem.

Version-Release number of selected component (if applicable):
2.6.12-1.1398_FC4smp kernel

How reproducible:
Always

Steps to Reproduce:
1. edit /etc/exports or use system-config-nfs
2.
3.
  

Actual Results:  Error message as described, susbsequently mount fails

Expected Results:  Filsystem should be exported, 

Additional info:

Have seen a very similar error reported for FC4 but no record of this with FC3

Comment 1 Adrian McMenamin 2005-08-08 13:09:13 UTC
What appears in /var/log/messages when I attempt to mount this:


Aug  8 14:06:55 mayday kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
Aug  8 14:06:57 mayday dhcpd: DHCPDISCOVER from 00:d0:f1:03:12:b9 via eth0
Aug  8 14:06:58 mayday dhcpd: DHCPOFFER on 192.168.61.55 to 00:d0:f1:03:12:b9
via eth0
Aug  8 14:06:58 mayday dhcpd: Wrote 1 leases to leases file.
Aug  8 14:06:58 mayday dhcpd: DHCPREQUEST for 192.168.61.55 (192.168.61.50) from
00:d0:f1:03:12:b9 via eth0
Aug  8 14:06:58 mayday dhcpd: DHCPACK on 192.168.61.55 to 00:d0:f1:03:12:b9 via eth0
Aug  8 14:06:58 mayday rpc.mountd: bad path in mount request from 192.168.61.55:
"192.168.61.50:/home/adrian/linux-sh/initrd"


Comment 2 Adrian McMenamin 2005-08-08 13:16:27 UTC
sorry, above should say: have seen a similar bug reported for FC3, but NOT FC4

Comment 3 Steve Dickson 2005-08-08 14:49:48 UTC
The "rpc.idmapd: nfsdreopen: Opening..." is a known problem that
is fixed in a updated release of nfs-utils. Please upgrade 
your nfs-utils and try again... 

Comment 4 Adrian McMenamin 2005-08-08 14:56:40 UTC
Currently using nfs-utils-1.0.7-10. Not aware that yum has ever offered me
anything else...but will seek to update now. 

Comment 5 Steve Dickson 2005-08-08 15:05:51 UTC
hmm it appears the fix went in around 1.0.7-8 (see bz158188)...

Comment 6 Adrian McMenamin 2005-08-08 15:40:43 UTC
Downgraded to 1.0.7-8 and still had the problem... /var/lib/nfs/xtab remains empty

[root@mayday ~]# exportfs -av
exporting 192.168.61.55/255.255.255.0:/home/adrian/linux-sh/initrd
[root@mayday ~]# cat /var/lib/nfs/xtab
[root@mayday ~]#

Upgraded again and the problem remains...

Comment 7 Adrian McMenamin 2005-08-08 15:59:25 UTC
From the client side it looks like this...

IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.61.50, my address is 192.168.61.55
IP-Config: Complete:
      device=eth0, addr=192.168.61.55, mask=255.255.255.0, gw=192.168.61.50,
     host=192.168.61.55, domain=, nis-domain=(none),
     bootserver=192.168.61.50, rootserver=192.168.61.50, rootpath=
Looking up port of RPC 100003/3 on 192.168.61.50
Looking up port of RPC 100005/3 on 192.168.61.50
Root-NFS: Server returned error -13 while mounting
192.168.61.50:/home/adrian/linux-sh/initrd
VFS: Unable to mount root fs via NFS, trying floppy.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)


Comment 8 Adrian McMenamin 2005-08-10 00:59:23 UTC
If I do not specify an NFS root in the client kernel command line but instead
rely on the client attempting to mount /tftpboot/X.X.X.X (and assuming that is
exported), it will mount the root

Comment 9 Edgar Hoch 2005-09-27 00:44:18 UTC
I have got the same error message, and 'exportfs' shows nothing,
but mounting from remote hosts works.
Kernel 2.6.12-1.1456_FC4smp x86_64
nfs-utils-1.0.7-11


Comment 10 Steve Dickson 2006-07-25 04:26:29 UTC
This is fixed in later version nfs-utils-1.0.7-19

Comment 11 Christian Iseli 2007-01-22 10:08:50 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 12 petrosyan 2008-02-28 09:14:56 UTC
Fedora Core 4 is no longer maintained.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.


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