Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Problem with nfs mounts of bind mounted directories|
|Product:||[Fedora] Fedora||Reporter:||Terry Barnaby <terry1>|
|Component:||nfs-utils||Assignee:||Jeff Layton <jlayton>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-08-04 08:42:26 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Terry Barnaby 2007-12-15 02:09:12 EST
On my server I have a hard disk partition mounted on /data. In this partition I have a directory /home with all of the users files. The /data/home directory is mounted using the --bind option to /home. On a client system I can NFS mount /home and /data from the server. However the clients /data directory ends up being actually a mount of /home ! This worked fine under FC6. There is a message in /var/log/messages on the server: mountd: /home and /data have same filehandle for *.kingnet, using first This seems like a nfs-utils or kernel bug to me ... Kernel: 184.108.40.206-63.fc8 How reproducible: Solid fault. Steps to Reproduce: 1. Mount using --bind a partitions subdirectory to somewhere. 2. Export both mount points. 3. On a client mount both mount points.
Comment 1 Jeff Layton 2008-02-05 10:55:30 EST
mountd defaults to using the uuid of the filesystem or the major/minor number to generate the device portion of the filehandle (since this is generally invariant between reboots, and is usually unique). In this situation it's not unique and the server has no way to know *which* export the client wants when this comes in. This is not easily changeable -- if it worked in older kernels it was probably a coincidence... You can probably work around this by setting fsid= export options on each of these exports. Maybe give /home fsid=1 and /data fsid=2 or something. That should make each export have explicitly different filehandles.
Comment 2 Jeff Layton 2008-08-04 08:42:26 EDT
I don't think there's anything that can be done with this. Using the UUID gets around many problems with stale filehandles when device ordering changes. Since there's been no update to this in several months. I'm going to close this as NOTABUG and presume that the workaround I proposed will fix this for you.