(In reply to Ashima Rawat from comment #0)
> Description of problem:
> 
> On Red Hat 7.x systems if you try to access local filesystems using the
> automounter through /net then the shell and mount could lock up *if* the
> filesystem your accessing is double exported.
> 
> Version-Release number of selected component (if applicable):
> 
> RHEL 7.0
> 
> 
> How reproducible:
> Export the shares and then try to access local filesystems using the
> automounter through /net.
> 
> 
> Steps to Reproduce:
> 1. Exported the shares on RHEL 7.2 machine identical as yours.
>  
> [root@dhcp8-30 ~]# exportfs -rav
> exporting *:/tmp
> exporting *:/export
> exporting *:/

What is in /etc/exports?

Below is the entry from exportfs file:

# cat /etc/exports
/ *(rw,insecure,async)
/export *(rw,insecure,async)
/tmp *(rw,insecure,async)

Also autofs debugging logs during the time of issue:

Jul 22 08:02:17 dhcp8-30 automount[1219]: st_expire: state 1 path /net
Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_proc: exp_proc = 140522986755840 path /net
Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: got thid 140522986755840 path /net stat 0
Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp 140522986755840 finished, switching from 2 to 1
Jul 22 08:02:17 dhcp8-30 automount[1219]: st_ready: st_ready(): state = 2 path /net
Jul 22 08:02:18 dhcp8-30 automount[1219]: st_expire: state 1 path /misc
Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_proc: exp_proc = 140522986755840 path /misc
Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: got thid 140522986755840 path /misc stat 0
Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp 140522986755840 finished, switching from 2 to 1

(In reply to Ashima Rawat from comment #4)
> Also autofs debugging logs during the time of issue:
> 
> Jul 22 08:02:17 dhcp8-30 automount[1219]: st_expire: state 1 path /net
> Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_proc: exp_proc =
> 140522986755840 path /net
> Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: got thid
> 140522986755840 path /net stat 0
> Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp
> 140522986755840 finished, switching from 2 to 1
> Jul 22 08:02:17 dhcp8-30 automount[1219]: st_ready: st_ready(): state = 2
> path /net
> Jul 22 08:02:18 dhcp8-30 automount[1219]: st_expire: state 1 path /misc
> Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_proc: exp_proc =
> 140522986755840 path /misc
> Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: got thid
> 140522986755840 path /misc stat 0
> Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp
> 140522986755840 finished, switching from 2 to 1

I doubt that is what is in the log at the time of the mount
attempt. What I see in the log is the mount(8) bind mount command
hang but that is on an xfs file system.

What file system is this?

Which file system is this being seen on?
Clearly I can't try and duplicate this if I don't know that.

(In reply to Ian Kent from comment #6)
> Which file system is this being seen on?
> Clearly I can't try and duplicate this if I don't know that.

Never mind, I don't think this is file system specific and
it definitely isn't related to NFS either.

Here's an update on what I've found so far.

The problem isn't related to NFS.
It isn't related to autofs either.

It is due to the root file system being set propagation shared
at boot by systemd.

First let me explain what autofs does for its multi-mount map
entries.

Consider an auto.master entry:

/multi      /etc/auto.test

and an /etc/auto.test which contains:

test    /        server:/exports \
        /tmp     server:/exports/tmp \
        /lib     server:/exports/lib

where the directories /exports, /exports/tmp and /exports/lib
exist.

This is called a multi-mount entry and the individual mounts
of the sub paths are called offsets.

You can see that the root offset (/) is not an autofs file
system which means the offsets, /tmp and /lib, are no longer
within an autofs file system and won't be able to trigger
a mount.

In order to trigger offset mounts an autofs trigger mount
is mounted at each offset.

Now, if server is the local machine autofs will attempt to
bind mount them instead of NFS mounting them.

Assume that all three paths, /exports, /exports/tmp and
/exports/lib are within the root file system.

Then run "ls /multi/test".

This will result in a bind mount of <root fs device> on
/multi/test and two autofs trigger mounts on /multi/test/lib
and /multi/test/tmp.

Because the file system containing these two offset mounts is
shared (mounts propagate in both directions, to the parent
and slaves) both of these autofs mounts will propagate back
to the root file system as mounts of /exports/lib and
/exports/tmp neither of which are managed by automount(8)
effectively blocking access by the actual trigger mounts
when they are accessed.

Running "mount --make-rprivate /" or "mount --make-rslave /"
and performing the above accesses results in the automount(8)
functioning as expected.

If /exports/lib and /exports/tmp are separate file systems
then the extra mounts are propagated along with another
for each that covers the propagated autofs trigger mount
resulting in the multi-mount working but with extra unwanted
mounts due to the propagation.

So far it does not seem possible to change this behaviour
by having automount(8) use mount options related to mount
propagation.

It may be possible to change automount(8) (I'm thinking
about how I might do that now) to make the situation a
little better behaved but there is no way to avoid these
propagated mounts that I can see.

Ian

(In reply to Ian Kent from comment #10)
> 
> If /exports/lib and /exports/tmp are separate file systems
> then the extra mounts are propagated along with another
> for each that covers the propagated autofs trigger mount
> resulting in the multi-mount working but with extra unwanted
> mounts due to the propagation.

In the above I mean that /exports/lib and /exports/tmp are
separate "local" file systems.

Since the case here relates to the autofs hosts map, which
essentially creates a multi-mount entry from the server
exports list, a work around is to add the "nobind" option
to the master map entry for the hosts map.

For example:

/net      -hosts nobind

which will avoid bind mounting and use NFS for mounting
instead, and will work as expected.

There is no workaround for colon escaped local paths, for
example the multi-mount entry:

test    /        :/exports \
        /tmp     :/exports/tmp \
        /lib     :/exports/lib

will not work properly in the way described in comment #10.

*** Bug 1596154 has been marked as a duplicate of this bug. ***

Created attachment 1458628 [details]
Patch - set bind mount as propagation slave

Created attachment 1458629 [details]
Patch - add master map pseudo options for mount propagation

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://access.redhat.com/errata/RHBA-2018:3283

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days