autofs does not recover from failure to read maps on startup

Bug #1614282 reported by Maciej Puzio on 2016-08-17
This bug affects 2 people
Affects Status Importance Assigned to Milestone
autofs (Ubuntu)

Bug Description

This problem is occurring on Ubuntu 16.04 system where autofs and sssd are both installed, sssd is configured to provide automount maps, and nsswitch.conf directs autofs to use sssd. In a situation when both sssd and autofs start before network is up (which happens out-of-the-box because of bug 1588915), sssd is unable to obtain automount maps from the LDAP server, nor any other data, and serves information from its cache. Autofs does not appear to retrieve cached automount maps from sssd, which can be verified with automount -m not showing any maps. This is accompanied by an error in syslog: "setautomntent: lookup(sss): setautomntent: No such file or directory". It goes without saying that shares are not mounted either.

When network is finally up, sssd is able to connect to the LDAP server, and autofs retrieves automount maps (automount -m now displays maps as expected). However autofs does not attempt to mount shares specified by these maps. Attempting to access these shares does not help; it is necessary to manually restart autofs service.

Steps to reproduce:
1. Start the machine with network interfaces not configured (e.g. cables unplugged).
2. Verify that sssd works and serves data (e.g. getent passwd, etc).
3. Check that autofs does not see maps and has not mounted shares: automount -m, ls /shares/...
   (Possibly) expected result: autofs obtains cached maps and mounts shares as specified.
4. Plug network cable and configure the interface: ifup eth0
5. Verify that autofs now sees maps: automount -m
6. Check that shares specified in maps are still unmounted: ls /shares/...
   Expected result: shares will now be mounted.
7. Restart autofs: systemctl restart autofs
8. Verify that shares are now mounted.
   This is as expected, but step #7 shouldn't be necessary.

$ lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

$ apt-cache policy autofs sssd-ldap libpam-sss libnss-sss sssd-tools
  Installed: 5.1.1-1ubuntu3
  Installed: 1.13.4-1ubuntu1
  Installed: 1.13.4-1ubuntu1
  Installed: 1.13.4-1ubuntu1
  Installed: 1.13.4-1ubuntu1
[Note: Package sssd is not installed, because it is a virtually empty package that pulls a numbed of unneeded dependencies.]

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in autofs (Ubuntu):
status: New → Confirmed
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I uploaded a newer autofs to Zesty yesterday. This restores the systemd service, which was previously being replaced by an upstart job. On 16.04, I suspect (but haven't checked) that this caused a fallback to the init.d script. So on Zesty, behaviour may have changed in relation to this bug.

I'm not really sure how to address the issue you're facing, but we appreciate the report. Suggestions on how to do this properly welcome (I see some in bug 1588915?)

Changed in autofs (Ubuntu):
importance: Undecided → Medium
Maciej Puzio (maciej-puzio) wrote :

Robie, thank you for your comment.
There is a number of bugs related to autofs and sssd present in Xenial. A partial attempt to sort out this situation can be found in bug 1566508, comment #20 ( ). However, this is compounded by problems with network interface initialization on startup: bug 1588915, comment #12 ( ). Both of these bug reports deal with several issues that are difficult to untangle.
Regarding the issue of missing autofs.service file, it a subject of bug 1614248.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers