Bug 1291919

Summary: Autofs NFS network mounts do not work when using a VPN
Product: [Fedora] Fedora Reporter: Robert Abram <rob_abram>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 23CC: ikent
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-30 23:58:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Abram 2015-12-15 21:47:20 UTC
Description of problem:

Recently Autofs has stopped working normally when working remotely with a VPN.  Before, I booted the computer and then immediately connect to a VPN. After that I could click on any autofs mount point and they would show the remote contents.  Now after connecting to the VPN, clicking on the mount points does not show anything and autofs has to be manually restarted to get the mount points to work.

This Fedora laptop is a FreeIPA client and the shares are discovered by autofs through LDAP lookup.  The LDAP is not available until the VPN is connected.  Each NFS share has the --ghost option set so the mount points are always visible.  Each ghost/mount point is visible even if the VPN is not connected, so some part of FreeIPA mount configuration is persisting between reboots.

If I am in the office where the NFS servers are located, autofs works normally and there is no problem accessing the NFS shares.


Version-Release number of selected component (if applicable):
autofs-5.1.1-3.fc23.x86_64

How reproducible: 100%


Steps to Reproduce:
1. Connect to VPN where NFS shares are located
2. Try accessing mount directory via Nautilus or Terminal


Actual results:
Autofs mount points are not automatically mounted after VPN is connected and the mount point is accessed.

Expected results:
The remote share contents are visible after connecting to the VPN and clicking on the mount point.


Additional info:
I recently upgraded the laptop to Fedora 23, but I cannot remember if this started at the same time as the upgrade to Fedora 23 or after some update.

Comment 1 Robert Abram 2015-12-15 22:30:05 UTC
Notes: 

  I've changed the host names to dummy names.

  This configuration has been working for me since Fedora 21 and has survived upgrades to FC 22 and FC 23 without changes.

--
These are the autofs configuration files in use
--
/etc/autofs_ldap_auth.conf

<autofs_ldap_sasl_conf
     usetls="yes"
     tlsrequired="yes"
     authrequired="yes"
     authtype="GSSAPI"     
/>


/etc/sysconfig/autofs

MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="automountMapName"
ENTRY_ATTRIBUTE="automountKey"
VALUE_ATTRIBUTE="automountInformation"

LDAP_URI="ldap://host.domain.org,ldap://host2.domain.org"
SEARCH_BASE="cn=secure,cn=automount,dc=domain,dc=org"


--
This is the autofs debug output when the service is started with the VPN connected.
--
Dec 15 15:17:17 host.domain.org systemd[1]: Starting Automounts filesystems on demand...
Dec 15 15:17:17 host.domain.org automount[5921]: Starting automounter version 5.1.1-3.fc23, master map auto.master
Dec 15 15:17:17 host.domain.org automount[5921]: using kernel protocol version 5.02
Dec 15 15:17:17 host.domain.org automount[5921]: lookup_nss_read_master: reading master sss auto.master
Dec 15 15:17:17 host.domain.org automount[5921]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:17 host.domain.org automount[5921]: master_do_mount: mounting /-
Dec 15 15:17:17 host.domain.org automount[5921]: automount_path_to_fifo: fifo name /run/autofs.fifo--
Dec 15 15:17:17 host.domain.org automount[5921]: lookup_nss_read_map: reading map sss auto.direct
Dec 15 15:17:17 host.domain.org automount[5921]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:17 host.domain.org automount[5921]: lookup_nss_read_map: reading map files auto.direct
Dec 15 15:17:17 host.domain.org automount[5921]: mounted direct on /shared/backups with timeout 300, freq 75 seconds
Dec 15 15:17:17 host.domain.org automount[5921]: do_mount_autofs_direct: mounted trigger /shared/backups
Dec 15 15:17:17 host.domain.org automount[5921]: mounted direct on /shared/documents with timeout 300, freq 75 seconds
Dec 15 15:17:17 host.domain.org automount[5921]: do_mount_autofs_direct: mounted trigger /shared/documents
Dec 15 15:17:17 host.domain.org automount[5921]: mounted direct on /shared/secure with timeout 300, freq 75 seconds
Dec 15 15:17:17 host.domain.org automount[5921]: do_mount_autofs_direct: mounted trigger /shared/secure
Dec 15 15:17:17 host.domain.org automount[5921]: mounted direct on /shared/pictures with timeout 300, freq 75 seconds
Dec 15 15:17:17 host.domain.org automount[5921]: do_mount_autofs_direct: mounted trigger /shared/pictures
Dec 15 15:17:17 host.domain.org automount[5921]: st_ready: st_ready(): state = 0 path /-
Dec 15 15:17:17 host.domain.org systemd[1]: Started Automounts filesystems on demand.

--
This is the autofs debug output when the service is started with the VPN disconnected.
--
Dec 15 15:17:39 host.domain.org systemd[1]: Starting Automounts filesystems on demand...
Dec 15 15:17:39 host.domain.org automount[6504]: Starting automounter version 5.1.1-3.fc23, master map auto.master
Dec 15 15:17:39 host.domain.org automount[6504]: using kernel protocol version 5.02
Dec 15 15:17:39 host.domain.org automount[6504]: lookup_nss_read_master: reading master sss auto.master
Dec 15 15:17:39 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: setautomntent: lookup(sss): setautomntent: No such file or directory
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_master: auto.master not found, replacing '.' with '_'
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: setautomntent: lookup(sss): setautomntent: No such file or directory
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_master: reading master files auto.master
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_master: lookup(file): read entry /misc
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_master: lookup(file): read entry /net
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_master: lookup(file): read entry +dir:/etc/auto.master.d
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_master: reading master dir /etc/auto.master.d
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_master: lookup(dir): scandir: /etc/auto.master.d
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_master: lookup(file): read entry +auto.master
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_master: reading master sss auto.master
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: setautomntent: lookup(sss): setautomntent: No such file or directory
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_master: reading master files auto.master
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: lookup(file): failed to read included master map auto.master
Dec 15 15:17:51 host.domain.org automount[6504]: master_do_mount: mounting /misc
Dec 15 15:17:51 host.domain.org automount[6504]: automount_path_to_fifo: fifo name /run/autofs.fifo-misc
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_map: reading map file /etc/auto.misc
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: mounted indirect on /misc with timeout 300, freq 75 seconds
Dec 15 15:17:51 host.domain.org automount[6504]: st_ready: st_ready(): state = 0 path /misc
Dec 15 15:17:51 host.domain.org automount[6504]: master_do_mount: mounting /net
Dec 15 15:17:51 host.domain.org automount[6504]: automount_path_to_fifo: fifo name /run/autofs.fifo-net
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_nss_read_map: reading map hosts (null)
Dec 15 15:17:51 host.domain.org automount[6504]: parse_init: parse(sun): init gathered global options: (null)
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_map: lookup(hosts): read hosts map
Dec 15 15:17:51 host.domain.org automount[6504]: lookup_read_map: lookup(hosts): map not browsable, update existing host entries only
Dec 15 15:17:51 host.domain.org automount[6504]: mounted indirect on /net with timeout 300, freq 75 seconds
Dec 15 15:17:51 host.domain.org automount[6504]: st_ready: st_ready(): state = 0 path /net
Dec 15 15:17:51 host.domain.org systemd[1]: Started Automounts filesystems on demand.

Comment 2 Robert Abram 2015-12-28 17:49:59 UTC
As a workaround, I wrote a NetworkManager dispatcher script to restart the autofs service when the VPN is connected.  

/etc/NetworkManager/dispatcher.d/40-vpn

#!/bin/bash

CONN_NAME='Connection Name Here'

CONNECTED=$(nmcli con show "$CONN_NAME" | grep "VPN.VPN-STATE:" | grep "connected" | wc -l)

if [ $CONNECTED == "1" ]; then

   systemctl restart autofs.service

fi

Comment 3 Ian Kent 2015-12-29 04:00:07 UTC
(In reply to Robert Abram from comment #2)
> As a workaround, I wrote a NetworkManager dispatcher script to restart the
> autofs service when the VPN is connected.  
> 
> /etc/NetworkManager/dispatcher.d/40-vpn
> 
> #!/bin/bash
> 
> CONN_NAME='Connection Name Here'
> 
> CONNECTED=$(nmcli con show "$CONN_NAME" | grep "VPN.VPN-STATE:" | grep
> "connected" | wc -l)
> 
> if [ $CONNECTED == "1" ]; then
> 
>    systemctl restart autofs.service
> 
> fi

I thought I had commented on this but I see I haven't.

This approach really is the only way around this difficulty
as autofs needs to have the mount information when it is
started and if it isn't available it will start with what
it has.

There isn't any caching of previous map information, once
automount exits the information has gone. And really that
has to be the way it is since there's no way to know how
maps may have changed.

If maps then become available it needs to be told to update
what it has seen.

But once the maps become available it will re-connect to
left over mounts that are present in the mount table if
there are any.

This hasn't changed for a long time so something outside of
autofs must have changed recently, perhaps the startup order
or how long it takes other dependent sub-systems to start has
changed.

A reload action should be sufficient and is probably better
in terms being least disruptive.

Comment 4 Robert Abram 2015-12-30 23:58:50 UTC
I understand, I'll close this issue. Thanks!