Bug 1331207 - NFSv4 export of "/" doesn't respect "crossmnt" export option
Summary: NFSv4 export of "/" doesn't respect "crossmnt" export option
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nfs-utils
Version: 6.7
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Yongcheng Yang
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1324930 1353680
TreeView+ depends on / blocked
 
Reported: 2016-04-28 02:16 UTC by Ramandeep Arora
Modified: 2020-05-14 15:10 UTC (History)
6 users (show)

Fixed In Version: nfs-utils-1.2.3-73.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1353680 (view as bug list)
Environment:
Last Closed: 2017-03-21 11:23:54 UTC
Target Upstream Version:


Attachments (Terms of Use)
The back ported patches (5.21 KB, patch)
2016-07-07 17:20 UTC, Steve Dickson
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0741 0 normal SHIPPED_LIVE nfs-utils bug fix update 2017-03-21 12:44:36 UTC

Description Ramandeep Arora 2016-04-28 02:16:23 UTC
Description of problem:


I have a customer who is exporting his "/" filesystem with "crossmnt"
option.

When he mounts it on NFS client, he is not able to see any thing under
the sub-filesystems of "/".

Let say, on the NFS server he has /, /var and /var/log as three separate
filesystems. When he mounts "/", exported with "crossmnt" option, on the
NFS client he is not able to see anything under /mount_point/var on the
NFS client.

But if he exports "/var" with crossmnt option instead of "/" and mounts
it on the NFS client, he is able to see files under /mount_point/var/log.

Yes, if he exports "/" and /var both then he is able to see files under 
/mount_point/var on the NFS client. But he doesn't want to export every
filesystem exclusively and instead wants "/" exported with corssmnt
option and access underlying filesystems on the NFS client. 


Is this an expected behaviour or a bug?

Version-Release number of selected component (if applicable):

kernel-2.6.32-573.3.1.el6.x86_64
nfs-utils-1.2.3-64.el6.x86_64

Comment 2 J. Bruce Fields 2016-04-29 14:49:21 UTC
I believe the automatic mounting of child mounts was always intentional, though it was only documented by upstream nfs-utils patch 0f1f4e7278c1 "exports.man: improve documentation of 'nohide' and 'crossmnt'".

I wonder if this could be fixed by 1e4a4c3816ca "mountd: fix next_mnt handling for "/""?

Comment 3 Dave Wysochanski 2016-06-20 14:58:39 UTC
Recommending for 6.9 priority based on:
- trivial to reproduce
- patch exists believed to fix the problem

Comment 4 Dave Wysochanski 2016-06-20 15:47:41 UTC
I've confirmed a nfs-server based on F23 (nfs-utils-1.3.3-7.rc4.fc23.x86_64) which contains 1e4a4c3816ca this problem doesn't exist.  I used the following export which is from the case:
/ nfs-client(ro,crossmnt,nohide,no_root_squash)

From a RHEL6.7 nfs-client, if I mount the above I can see the 'boot' directory which is on a separate filesystem.

Then I moved to a RHEL6.7 NFS server, and mount with the same NFS client and export.  However, 'ls' does not show the 'boot' directory so the problem exists.

I then built a test package nfs-utils-1.2.3-64.el6_7.bz1331207.1 with the above commit and updated a RHEL6 NFS server and rebooted it.  Unfortunately this test package does not solve the problem so there must be more to this bug than the one patch previously mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1331207#c2

SteveD - do you have any idea what else may be required to fix this on RHEL6?  I did not investigate further with gdb or looking through patches.

Comment 6 Steve Dickson 2016-07-06 13:32:25 UTC
(In reply to Dave Wysochanski from comment #4)
> I've confirmed a nfs-server based on F23 (nfs-utils-1.3.3-7.rc4.fc23.x86_64)
> which contains 1e4a4c3816ca this problem doesn't exist.  I used the
> following export which is from the case:
> / nfs-client(ro,crossmnt,nohide,no_root_squash)
> 
> From a RHEL6.7 nfs-client, if I mount the above I can see the 'boot'
> directory which is on a separate filesystem.
> 
> Then I moved to a RHEL6.7 NFS server, and mount with the same NFS client and
> export.  However, 'ls' does not show the 'boot' directory so the problem
> exists.
> 
> I then built a test package nfs-utils-1.2.3-64.el6_7.bz1331207.1 with the
> above commit and updated a RHEL6 NFS server and rebooted it.  Unfortunately
> this test package does not solve the problem so there must be more to this
> bug than the one patch previously mentioned in
> https://bugzilla.redhat.com/show_bug.cgi?id=1331207#c2
> 
> SteveD - do you have any idea what else may be required to fix this on
> RHEL6?  I did not investigate further with gdb or looking through patches.
Off the top no... but looking at the rpc.mountd debug of a f24 server

rpc.mountd: Version 1.3.3 starting
rpc.mountd: auth_unix_ip: inbuf 'nfsd 172.31.1.28'
rpc.mountd: auth_unix_ip: client 0x559968cce720 '*'
rpc.mountd: nfsd_fh: inbuf '* 1 \x00000000'
rpc.mountd: nfsd_fh: found 0x559968cd7830 path /
rpc.mountd: nfsd_export: inbuf '* /boot'
rpc.mountd: nfsd_export: found 0x559968cd7820 path /boot
rpc.mountd: nfsd_fh: inbuf '* 6 \x8cceab6d5fee4b629d1931b7c47465c0'
rpc.mountd: nfsd_fh: found 0x559968cd7830 path /

It uses the same filehandle for both '/' and '/boot'

On both a RHEL6 and RHEL7 server '/' filehandle is not found:

rpc.mountd: auth_unix_ip: inbuf 'nfsd 172.31.1.28'
rpc.mountd: auth_unix_ip: client 0x7ff3b560e980 '*'
rpc.mountd: nfsd_fh: inbuf '* 1 \x00000000'
rpc.mountd: nfsd_fh: found 0x7ff3b5611e70 path /
rpc.mountd: nfsd_export: inbuf '* /boot'
rpc.mountd: nfsd_export: found 0x7ff3b5611e60 path /boot
rpc.mountd: nfsd_fh: inbuf '* 6 \x57784f7db1fc44df97a971097e3b88b9'
rpc.mountd: nfsd_fh: found (nil) path (null)

Comment 7 Steve Dickson 2016-07-07 16:35:25 UTC
Here are the upstream commits that are needed:

commit 686a9bef21a02f4eb9d9f15266f205d6f1e78d41
Author: NeilBrown <neilb>
Date:   Wed Feb 25 16:47:56 2015 -0500

    mountd: fix next_mnt handling for "/"

commit 3f18123e86cc52e2c6789a37815db8d5b87fca74
Author: Vivek Trivedi <t.vivek>
Date:   Wed Sep 16 11:14:03 2015 -0400

    mountd: fix mount issue due to comparison with uninitialized uuid

commit f4d4478671077bac63ade4a3102f9ce864d27c8d
Author: NeilBrown <neilb>
Date:   Tue May 7 11:46:18 2013 -0400

    mountd: Fix is_subdirectory again

commit 249999c5d4fd5a161dc09359fef8d0a1c01dc3f5
Author: Steve Dickson <steved>
Date:   Wed Jul 6 11:09:07 2016 -0400

    mountd: fix is_subdirectory to understand '/'

Comment 8 Steve Dickson 2016-07-07 16:44:59 UTC
(In reply to Steve Dickson from comment #7)
> Here are the upstream commits that are needed:
Note... The above commit ids are not valid ids.
Here are the correct ids 


commit 0f1f4e7278c1bc93d54da1026dfe484f27bcd873
Author: NeilBrown <neilb>
Date:   Thu Feb 26 14:10:35 2015 -0500

    exports.man: improve documentation of 'nohide' and 'crossmnt'

commit 1e4a4c3816ca5a1e1a345117a201d9cc6c468beb
Author: NeilBrown <neilb>
Date:   Wed Feb 25 16:47:56 2015 -0500

    mountd: fix next_mnt handling for "/"

commit 78240c41be17bd20d5fb5b70b6f470d8e779adee
Author: Vivek Trivedi <t.vivek>
Date:   Wed Sep 16 11:14:03 2015 -0400

    mountd: fix mount issue due to comparison with uninitialized uuid

commit 23d3980b6cfea4e9056d9b7b81e48b4fefc645e0
Author: NeilBrown <neilb>
Date:   Tue May 7 11:46:18 2013 -0400

    mountd: Fix is_subdirectory again


commit 249999c5d4fd5a161dc09359fef8d0a1c01dc3f5
Author: Steve Dickson <steved>
Date:   Wed Jul 6 11:09:07 2016 -0400

    mountd: fix is_subdirectory to understand '/'

Comment 9 Steve Dickson 2016-07-07 17:20:56 UTC
Created attachment 1177400 [details]
The back ported patches

Comment 15 Yongcheng Yang 2016-11-02 04:00:35 UTC
Moving to VERIFIED according to test logs of Comment #14.

And including this automatic case as regression test in the future.

Comment 18 errata-xmlrpc 2017-03-21 11:23:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0741.html


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