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:
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 220.127.116.11 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):
Steps to Reproduce:
1. edit /etc/exports or use system-config-nfs
Actual Results: Error message as described, susbsequently mount fails
Expected Results: Filsystem should be exported,
Have seen a very similar error reported for FC4 but no record of this with FC3
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
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:
sorry, above should say: have seen a similar bug reported for FC3, but NOT FC4
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...
Currently using nfs-utils-1.0.7-10. Not aware that yum has ever offered me
anything else...but will seek to update now.
hmm it appears the fix went in around 1.0.7-8 (see bz158188)...
Downgraded to 1.0.7-8 and still had the problem... /var/lib/nfs/xtab remains empty
[root@mayday ~]# exportfs -av
[root@mayday ~]# cat /var/lib/nfs/xtab
Upgraded again and the problem remains...
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
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
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)
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
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
This is fixed in later version nfs-utils-1.0.7-19
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 ?
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.