What happened to autofs in 13.2?

English Install/Boot/Login
#1

For something like 4 years I have been using autofs to easily cross access my home directories on two desktop machines always networked(but often rebooted to Windows), and a laptop that is only sporadically hooked into my home network. This has worked through 12.3. I recently began upgrading these three machines, starting with the laptop, to 13.2. These have been clean installs of 13.2 from an iso image on DVD. Almost immediately I discovered that the previous autofs scheme no longer worked. IN this scheme, suggested by lwfinger several years ago, I edited the auto.master file with an appended line:

/- auto.nfs

and then created the file auto.nfs on each machine to have the mounting pairs from the other two machines. For example, on 192.168.0.104 (a desktop machine) auto.nfs shows

/home/kyoto/home/lrk 192.168.0.102:/home/lrk
/home/siracusa/home/lrk 192.168.0.103/home/lrk

In addition, on each machine, I went into nfsserver in Yast2 and explicitly exported the /home/lrk directory on that machine to the mount points on the other two hosts. Then when I cd’ed into the appropriate directory on one machine (say siracusa) /home/kyoto/home/lrk I was able to see my /home/lrk directory on the kyoto machine.

This autofs scheme no longer works. There are several strange things about the 13.2 setup compared to 12.3. The first is that man autofs claims that /etc/init.d/autofs controls operation of the automount(8) daemons. On 12.3 this script exists, on 13.2 it does not. If I check the installed software in 13.2, autofs is installed. if I go into Yast2 Services Manager, autofs shows as enabled but inactive. At a console, if I type

rcautofs status

I obtain pretty much the same thing:

autofs.service - Automounts filesystems on demand
Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled)
Active: inactive (dead)
Docs: man:automount(8)
man:autofs(5)

with the addition that it is both inactive, and dead. In Services Manager one is offered buttons to Start/Stop and Enable/Disable. Neither seems to change the listed status of autofs, and neither seems to make it work.

In 12.3 if I used chkconfig autofs I got a message that it was either on or off. In 13.2 chkconfig autofs returns autofs: unknown service

So my first question would be: Is the /etc/init.d/autofs script really missing, or is autofs invoked somewhere else?
My next question would be: What does it mean for a service to be “dead”? And how does it get that way?

Another confusing thing is that on 13.2 the file /etc/autofs.conf and /etc/sysconfig/autofs both exist, while only /etc/sysconfig/autofs exists in 12.3. They appear to be much the same in terms of listed options, but the files are different in format.

I have not found much light shed on any of these points in other posts regarding autofs under 13.2. However, if I have missed something obvious, I apologize.

I am prejudiced to get this autofs setup running again since it has been so convenient for so long, and autofs continues to be claimed as convenient as I have found it in the past. I would welcome any suggestions for analysis and fixes.

Laurence Keefe

#2

I don’t know anything about autofs (never used it), but you might get a more usefull error message if you run:

sudo systemctl status

or click on “Status” in YaST->Services Manager.

A unit is inactive (dead) when it fails to start for some reason.

The “enabled” means that it is started during boot.

chkconfig doesn’t work in this case, as autofs has a native systemd unit. openSUSE is using systemd since years, the old sysvinit is not supported/available any more. Although systemd has some compatibility, it’s still possible to use sysvinit scripts, and the old commands (chkconfig e.g.) should work too with sysvinit scripts.

#3

I have autofs working without problems (on 13.2).

To set it up, I edited “/etc/auto.master” and added a line for “auto.nfs”. Then I created “auto.nfs” (actually copied from what I had with 13.1). I then used Yast Services Manager to set both “rpcbind” and “autofs” as enabled and started.

It has been working fine.

I did notice one issue. When using NetworkManager, system shutdown or reboot seems to stop NetworkManager first, then umount nfs volumes later. And that doesn’t work. It can result in the system hanging during shutdown. I tried manually umounting before shutdown, which works. But I then switched to “wicked”, which also solves the problem.

For my laptop, I switch back to NetworkManager when travelling (and I avoid accessing autofs file systems when away from home).

I do mount everything under “/nfsmounts”, and use symlinks so that I can access nfs file systems under other paths.

#4

it simply means it is not started. What happens if you try “systemctl start autofs.service”?

Another confusing thing is that on 13.2 the file /etc/autofs.conf and /etc/sysconfig/autofs both exist, while only /etc/sysconfig/autofs exists in 12.3. They appear to be much the same in terms of listed options, but the files are different in format.

/etc/autofs.conf is interpreted by automount daemon directly while /etc/sysconfig/autofs was shell script used by /etc/init.d/autofs. As the latter is no more used, this shell script is not really needed too.

“dead” does not really imply “failed to start”. It simply means service is not active. It may have never been started in the first place. In this case it says “enabled” so I expect that start was at least attempted on boot. “systemctl status autofs.service” should print last log messages and may explain more.

#5

I hate magical occurrences when dealing with my computers. However, the autofs processes on the two machines converted to 13.2 have miraculously come to life, possibly as the result of my typing “systemctl start autofs.service”, and that life now persists across reboot. I have yet to wait long enough for any of these directories to be unmounted due to inaction, but in some cases the autofs process is still showing enabled and running after 3 hours of just sitting there. All three machines (one still on 12.3) now can cross access my /home/lrk accounts on the other two machines. Thanks to all for the help and advice.

Laurence Keefe