Bug 425765 - Problem with nfs mounts of bind mounted directories
Problem with nfs mounts of bind mounted directories
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeff Layton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-15 02:09 EST by Terry Barnaby
Modified: 2008-08-04 08:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-04 08:42:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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[4612]: /home and /data have same filehandle for *.kingnet, using first

This seems like a nfs-utils or kernel bug to me ... 

Kernel: 2.6.23.8-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.

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