Bug 700825

Summary: Systemd automounts fail to handle connect/disconnect of network devices
Product: [Fedora] Fedora Reporter: vemcontact2
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: johannbg, johannbg, johannbg, lpoetter, metherid, mschmidt, notting, plautrba
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: 2012-01-25 19:40:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description vemcontact2 2011-04-29 14:08:19 UTC
Description of problem:

New-style systemd NFS automount from fstab mounts properly when system is connected to network on boot, but fails to mount when (1) a system is disconnected from the network on boot (e.g. laptop) and is then connected to the network; (2) a system is connected to the network, then disconnected for a time, then reconnected (e.g. NetworkManager changes from a wired connection to a wireless network connection; or (3) a system that is connected to the a public network establishes a VPN tunnel (such as OpenVPN) to the private network hosting the automount share.

In each failure case, the automount item also cannot be manually mounted using the "mount" command from the Linux command line; the command hangs and eventually times out.

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

systemd-25-1.fc15.x86_64
NetworkManager-0.8.998-4.git20110427.fc15.x86_64


Steps to Reproduce:

[This is one of several failure cases described above]

1.  On a laptop system, set up a "new style" automount entry in /etc/fstab for a NFS4 share:

192.168.2.1:/network-storage	/home/testuser1/network-storage	nfs4	comment=systemd.automount,wsize=4096,rsize=4096,user,soft,_netdev	0 0

2.  Boot system with a wired network connection to the network that is hosting the NFS4 share.  Confirm that systemd automounts the share properly.  Shut down system.

3.  Boot system with a wired network connection to a public network (i.e. not the network containing the NFS share to be mounted).

4.  Using NetworkManager, establish an OpenVPN tunnel to the network containing the NFS share to be mounted.  Ping the NFS server to confirm that it is reachable over the VPN connection.

5.  Using "mount," confirm that the NFS4 share has not been not mounted.  [I have also observed that nautilus, when used to view /home/testuser1, will "hang" while trying to display the directory's contents, presumably because it is waiting for the NFS4 directory to mount or fail to mount]

6.  From the command line, try to mount the directory manually using "sudo mount /home/testuser1/network-storage."  The command will "hang" the terminal and eventually fail.
  
Actual results:

The NFS4 share does not mount.

Expected results:

The NFS4 share automounts whenever the network state changes so as to make the NFS server available.

Additional info:

As best I can tell, systemd is not re-trying the automount each time NetworkManager changes the network state to bring up a new network connection (e.g. wired, wireless, or VPN connection becomes available, potentially giving the system a route to the previously-unavailable NFS share).

Systemd should probably re-try all automounts in fstab on each ifup-type change in network state, whether initiated manually or through NetworkManager.

Comment 2 vemcontact2 2011-04-29 18:51:35 UTC
I'm not building NetworkManager from source, so don't know if this helps or not, sorry.

Comment 3 vemcontact2 2011-05-01 00:35:48 UTC
Bill, so sorry -- I see that the git reference is an initscripts change.  I've applied it and, no, it does not help.

Comment 4 Fedora Admin XMLRPC Client 2011-10-20 16:27:06 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Jóhann B. Guðmundsson 2012-01-24 13:09:46 UTC
Is this still a problem or can this bug be closed?

Comment 6 Jóhann B. Guðmundsson 2012-01-25 19:40:14 UTC
Closing this bug feel free to reopen it if this is still an issue thanks.