Ubuntu

autofs needs to be restarted to pick up some shares

Reported by Tony Middleton on 2006-04-19
194
This bug affects 34 people
Affects Status Importance Assigned to Milestone
autofs5 (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Mathias Gug
Nominated for Maverick by Rob Shinn
autofs (Ubuntu)
Medium
Unassigned
Declined for Karmic by Mathias Gug
Nominated for Maverick by Rob Shinn
upstart (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Mathias Gug
Nominated for Maverick by Rob Shinn

Bug Description

I am using autofs to access shares on a Windows XP machine from a Kubuntu AMD64 machine. The problems applies in both Breezy and Dapper.

EDIT: confirmed with similar configuration on Intrepid with a NetApp filer hosting NFS. Server OS removed from summary.

When I first try to access the mount point via cd or in Konqueror it does not exist. However, if I then restart autofs (/etc/init.d/autofs restart) everythin then works OK. My config files are:

auto.master

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc /etc/auto.misc --timeout=60
#/misc /etc/auto.misc
#/net /etc/auto.net

/petunia /etc/petunia.misc --timeout=60

petunia.misc

#
# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

tony -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 ://192.168.1.2/tony
chris -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 ://192.168.1.2/chris
shared -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 ://192.168.1.2/SharedDocs
linuxbackups -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 ://192.168.1.2/linuxbackups

Tony Middleton (ximera) wrote :

This is still a problem in feisty

Tony Middleton (ximera) wrote :

This may be the same as Debian bug #332717

Erik Lander (erik-lander) wrote :

I had a similar problem, I'm using autofs to mount a nfs share as my home directory at boot. I also had to restart autofs manualy every boot. I disabled NetworkManager like this 'chmod -x /usr/sbin/NetworkManager*' and now it works without having to restart. Though my problem seemed to be that my automount map is stored in a ldap database. =P

Can confirm this too. I'm also storing my automount map in LDAP. After a fresh boot autofs loads the map from LDAP but does not initialze any mount points:

Configured Mount Points:
------------------------
/usr/sbin/automount --timeout=60 --ghost /data/nfs/home ldap ou=auto.home,ou=automount,dc=exampe,dc=com
/usr/sbin/automount --timeout=60 --ghost /data/nfs/shares ldap ou=auto.misc,ou=automount,dc=example,dc=com

Active Mount Points:
--------------------

In the mean while I've got a workaround to share. It look likes we need to reload autofs with the network refresh of NetworkManager. Maybe these files can be added to the package as a bugfix. It is not me to decide that:

/etc/network/if-down.d/autofs and /etc/network/if-up.d/autofs:

#!/bin/sh
[ "$IFACE" != "lo" ] || exit 0
/etc/init.d/autofs reload

Works for me

Michael Rickmann (mrickma) wrote :

Similar here with Gutsy (Edubuntu). I try to setup autofs with automount maps in LDAP and NetworkManager uninstalled. My guess is that autofs gets started before slapd, can not find the maps and decides nothing to do. A simple
update-rc.d -f autofs remove
update-rc.d autofs defaults 20
For me it works.
The changelog, however, states that autofs start was lowered to level 19 instead of level 20 (somewhen in 2005) because of other daemons relying on it.

Helge Stenström (h-stenstrom) wrote :

I have a similar problem. I mount /home and few other directories from NFS, with mount definitions taken from NIS. I have to manually /etc/init.d/autofs restart after each boot.
This is with Ubuntu 8.04, and I think the problem started with 7.10, perhaps with 7.04.

'chmod -x /usr/sbin/NetworkManager*' didn't seem to help.

Helge Stenström (h-stenstrom) wrote :

The solution by Sebastiaan Veldhuisen above works for me.

Tony Middleton (ximera) wrote :

This seems to be fixed in hardy - at least as far as my original problem with shares on a Window XP machine.

Daniel T Chen (crimsun) wrote :

Per submitter feedback. Please reopen if reproducible in 8.10 alpha.

Changed in autofs:
status: New → Fix Released
Helge Stenström (h-stenstrom) wrote :

Not fixed for me in 8.04.1, where NFS files are mounted with help from NIS. I will not reopen now, but will hopefully remember to test with 8.10 next month.

I reproduced this problem on a release installation of Ibex (8.10)
It's times like these that I'm glad I run FreeBSD on my servers. Ubuntu, a great desktop, lousy server.

Adam Katz (khopesh) wrote :

Reproduced on Ibex (8.10), none of the above proposed workarounds solved the issue.

The reason the above workarounds did not solve my issue was that my home directory was mounted via autofs, so something like a script run by NetworkManager, which requires a login, will not do the trick. I'm not sure why the /etc/network/*.d/ scripts didn't do it. I had to create an init script (attached).

Since the autofs-bump init script is a hack, I didn't know how to enter it with update-rc.d ... here's how to do it manually:

sudo -s
cp etc_init.d_autofs-bump /etc/init.d/autofs-bump
chmod 755 /etc/init.d/autofs-bump
cd /etc
for L in 2 3 4 5; do
  cd rc$L.d
  ln -s ../init.d/autofs-bump S99autofs-bump
  cd -
done

Adam Katz (khopesh) on 2009-02-12
Changed in autofs:
status: Fix Released → Incomplete
Adam Katz (khopesh) on 2009-02-12
description: updated
Chris LeBlanc (crleblanc) wrote :

I also saw this problem while using Ubuntu 8.10 x86_64. I think I may have found the source of the problem.

I'm using this computer in a corporate environment, where each users home directory is mounted using autofs, and authentication is done using NIS.

The ssh daemon and automounting of the user's home directory failed to work after rebooting, but I found a workaround and a possible cause. This computer is using NetworkManager, which is loaded with /etc/rc2.d/S28NetworkManager. Autofs is loaded as /etc/rc2.d/S19autofs, and ssh as /etc/rc2.d/S19ssh, which are both loaded prior to NetworkManager.

The first thing I tried was to move autofs to S29, and ssh to S30 (both above NetworkManager). This should ensure that a network connection exists before starting the ssh and autofs daemons. However this did not work, for the following reason. If one runs '/etc/init.d/NetworkManager restart', this command will return several seconds before a network connection is established. The exit code it returns is 0, so there is no indication of an error.

As a test, I added the line 'sleep 15' near the end of /etc/init.d/NetworkManager (so this script would wait for 15 seconds before exiting), and rebooted the computer. Both the autofs and ssh daemons worked correctly after this.

I'm not proposing the NetworkManager script waits for 15 seconds, but instead it should wait until a network connection is either established or has failed, and return the appropriate exit code. Also, the NetworkManager init script should probably be placed before any other scripts that require a working network connection.

Gustavo Spadari (gspadari) wrote :

The solution by Sebastiaan Veldhuisen above works for me on one machine, but not on other. Both machines have 9.04. I don't know what could be the difference.

My autofs master map is in LDAP, thus I experience this issue with Jaunty 9.04 server - this is slightly different, in that NetworkManager isn't involved here.

autofs needs restarting before network mounts are available, due to incorrect starting order, as S20autofs is earlier than S35networking...thus the canonical workaround would be:

update-rc.d -f autofs remove
update-rc.d autofs defaults 36

however this doesn't resolve the issue, so the 'get out of jail' move is:

echo -e '#!/bin/bash\n/etc/init.d/autofs restart\n' >/etc/dhcp3/dhclient-exit-hooks.d/autofs
chmod 755 /etc/dhcp3/dhclient-exit-hooks.d/autofs

This is quite a troublesome bug - this just works on Redhat 5, so gives the user a bad experience with Ubuntu 9.04 server

Changed in autofs (Ubuntu):
status: Incomplete → Confirmed

This bug is still at large in Ubuntu 9.10, as observed on the desktop x86-64 variant.

This may not be reproducible with 'static' configurations where the automount tables are configured in files, but when they are specified in nsswitch.conf as 'automount: ldap', this fails to initialise - restarting the autofs service is needed.

If needed, let me know what area of detail is required to reproduce this.

Ken Arnold (kenneth-arnold) wrote :

Our site configuration stores auto.master in NFS for ease of updating. (Yes it should perhaps move to LDAP, but that is beyond my control.) Karmic autofs starts correctly about half of the time, depending on whether the NFS mount finishes before autofs gets around to reading its config. (I'm not sure if this is the exact same bug.) We clearly want autofs to start when an interface comes up. (In fact, our particular configuration requires that a _particular_ interface be up, but that may be out of scope of this bug.)

Jay (jay-wharfs) wrote :

I'm still seeing this with
automount: files ldap

on 9.10 server x86_64.

seems to work okay once the machine is booted and /etc/init.d/autofs restart is run.

Heiko Harders (heiko-harders) wrote :

I have this problem as well: Ubuntu 9.10 and reading mount points from an ldap server. The ldap server is running on a guest virtual machine, while the host itself needs autofs. Tried moving autofs from S19 in the init scripts to S30 (after libnss-ldap and after qemu-kvm and libvirt-bin), but that didn't help. I also tried Sebastian Veldhuisen his suggestion, but that didn't work either.

fejes (anthony-fejes) wrote :

I am experiencing what I think is the same problem in 10.04. It wasn't a problem in any of the versions prior to this on the one machine, but an upgrade recently caused this to affect ~50% of cold boots.

It's not difficult to solve - once the failed login happens (home is not mapped), I go to one of the terminals (crtl-alt-F1), and issue:

sudo /etc/init.d/autofs reload

After this, I can switch back to the KDE/Gnome prompt and login through the graphical prompt, which is now crtl-alt-F8.

Tails (tails-tailszefox) wrote :

Problem is still there in the final release of Ubuntu 10.04. autofs isn't started at all when booting up, which mean I have to manually start it each time with a 'service autofs start'.

So far none of the workarounds I tried seem to work. This is pretty troublesome, as having to manually start autofs after each reboot is quite annoying.

ahenric (ahenric) wrote :

I also can confirm the problem in Kubuntu 10.04. Autofs is not started when booting, only with 'service autofs start'. It was working though in Kubuntu 9.10. So something changed again.

Robbie Williamson (robbiew) wrote :

Can anyone confirm whether or not this problem still exists in 10.04.1 or 10.10? I'm asking because we pushed out an upstart patch that works around an issue with writing to /dev/console in the kernel, which was causing certain services trying to write to /dev/console, not to start. See http://bugs.launchpad.net/bugs/554172 for details (warning, it's LONG)

For me, running Maverick, this problem still exists.
It seems autofs is starting up correctly when changing the upstart configuration file for autofs.

--- /tmp/autofs.conf.orig 2010-10-12 20:08:12.000000000 +0200
+++ /etc/init/autofs.conf 2010-10-10 21:25:34.000000000 +0200
@@ -2,7 +2,8 @@
 author "Chuck Short <email address hidden>"

 start on (filesystem
- and net-device-up IFACE!=lo)
+ and net-device-up )
 stop on runlevel[!2345]

 console output

It do have the impression that system startup takes longer.

Paul Omernik (leviathor) wrote :

I am noticing this in my Maverick installations, and am now seeing it in some of my 10.04.1 installations as well. I did not have this issue with 10.04 or previous, though I was (am) affected by the boot priority of NIS bug (569757), which affects auto mounts.

It seems that Hans' post #25 has alleviated the issue for me on one Maverick system; I've yet to upgrade/triage further Lucid/Maverick systems.

I can confirm that Hans' upstart configuration change in post #25 fixes the bug in Karmic 9.10. I didn't notice the start up time being any slower but I haven't measured it.

Jeremy Nickurak (nickurak) wrote :

Still hitting this bug under natty as well.

Claudio Bernardini (claudiob) wrote :

I had the same bug in the past but with 10.10 everything was smooth.
With Natty 11.04 the bug is hitting again.
When I restart autofs the automounter starts to work as expected.

Jeremy Nickurak (nickurak) wrote :

Is this an Ubuntu bug? Is there a configuration problem in Ubuntu? Upstart problem? Or is it an upstream issue? This has been kicking around for over 5 years now.

How does the workaround in post #25 work? It seems like that would start autofs as soon as any network device comes up, when what you'd want to do is only bring it up when a non-loopback device comes up..... so I'd expect the original version to work better than the workaround.

mrtvfuencxozd (mrtvfuencxozd) wrote :

post #25 did not seem to work for me (10.10).

In my case , NFS entries I need to mount are stored in a NIS server.
as a fix I've created the following file :
--
###/etc/init/waitnis.conf
description "Wait for NIS"
author "moi"
start on starting autofs
task

script
        while [ ! $(pgrep ypbind) ] ; do
        sleep 5
        done;
        sleep 5
end script
--

something similar can probably be created to check ldap/... before starting autofs

Daniel Miller (dmiller) wrote :

Bug still exists on Natty. A revised script for NetworkManager seems to fix it for me:

/etc/network/if-up.d/autofs

#!/bin/sh

# Local interface changes are irrelevant to this
if [ "$IFACE" = lo ]; then
    exit 0
fi

reload autofs

Hello Canonical guys,

I have this problem specially for new and fast machines. Boot is just too fast. If autofs uses network shares (nis, nis+, ldap), it only can start autofs after the network is up (upstart bug?). Another solution is to start immediatelly (for static entries) and, after network is up, reload the configuration. If the reload script does not hurt other cases, please add it to autofs5-ldap package.

This bug hurts enterprise clients. Other distribution just works with autofs/ldap. Ubuntu should even have a gui in order to easily configure autofs/ldap.

I also noticed a very similar problem with samba. As it got up before network, it does not find the DC and it avoids to auth users until it is restarted. This is very anoying, specially for a cups print server.

FYI, in my case, 11.04, reload autofs is not enough. I need to use restart autofs

Gergely Katona (gkatona) wrote :

I maintain a 10.04 LTS based cluster of workstations where each node is subject to some stress and need to be restarted once in a while. Autofs maps of nfs shares are communicated via LDAP. Autofs fails to initialize (or even start in some rare cases) in its default configuration in about 50% of all boots, making the nodes unusable until autofs is restarted. In addition to this bug sometimes bind mounts fail to initialize at boot and need a remount.
After trying out several suggested workarounds unsuccessfully I am using the following not too elegant rc.local script, which hammers autofs into submission (works 99% of the time). I also advise my users not to restart their computers unless absolutely necessary.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sleep 10
service autofs start &
sleep 60
service autofs restart &
sleep 60
service autofs restart &
sleep 60
mount -a

exit 0

Still present in oneiric 11.10

Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu):
status: New → Confirmed
Sorin Sbârnea (sorin-sbarnea) wrote :

I just want to add that I got the same bug on 11.10 and that the rc.local trick doesn't seem to work but if I run `reload autofs` once as a local user, it will start to work instantly!

Vernon Tang (vtang) on 2012-04-12
Changed in autofs5 (Ubuntu):
status: New → Confirmed
Thomas Schweikle (tps) wrote :

Same for Ubuntu 12.04 LTS. Since this isn't acceptable in a company environment I've stopped migrating to Ubuntu 12.04 from 10.04. It is something that has to be fixed before any further upgrades.

The whole thing doesn't work not only for Windows XP shares, it doesn't for NFS too. I have to restart autofs after all interfaces are up to make it work. The problem: autofs is started before *all* interfaces are up and running (only waiting on local-loopback). autofs then ignores any interface started afterwards.

Two solutions:
1. make autofs start *after* all configured interfaces are up, or
2. make autofs aware of additional interfaces, respecting and using them after additional interfaces are comming up.

At the moment autofs has to be restarted if interfaces come and go. If interfaces go it might take a long time until autofs exausts an error message about not being able to mount a share. If interfaces come up later autofs ignores them. Really bad, if autofs is used for automounting user homes or such stuff from centralized servers!

Charon (charon030) wrote :

We have the same problems on our clients within our company (ldap+nfs+autofs, 12.04). Because of this bug we started migrating to SUSE for new machines. A fix would be really great.

Hardy Heroin (hardy-heroin) wrote :

Ubuntu 12.04 LTS support here. I can confirm this bug. The automount service needs to retrieve the automount NFS maps auto_home and auto_group from LDAP which it is unable to do because the network isn't up yet. To make things a bit more complicated, these are Kerberized (krb5) NFSv4 mounts.
After automount fails once it fails and doesn't try again when the network is up.
It seems to me this could be a case for upstart to enforce network being up before (network) automounts are attempted or automount being at least so smart to try again some time later or when the networks are up.
This is a serious bug in large scale Linux environments. Of course there are workarounds such at the ones documented in this thread, but they are ugly and why should every user/administrator have to reinvent the wheel when it is clear what the problem is?

Pierre-Marie Dhaussy (pihemde) wrote :

I ha ve the same problem between Synology DS411j NAS shares and a Debian Wheezy autofs install.

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

Duplicates of this bug

Other bug subscribers