Suppose you have a linux network setup with automounter maps that come from the network (via
LDAP etc.) and you want to block some of them acting on a particular system. In our case we have an automount map that acts on
/opt and mounts various software packages from network shares. The problem with this is that you can’t then install your own stuff locally to
/opt, which is what a lot of Debian/Ubuntu packages expect to be able to do.
It turns out there is a option in the automounter for this sort of situation. There is a built-in map called
-null that blocks any further automounts to a particular mountpoint. In our case we want to block
auto.opt, so we add a line to
auto.master (somewhere before the bottom
Then restart the
autofs service (if stuff was mounted on
/opt then unmount it). Or reboot the system. You should find that you can put stuff in the local
To check the map is blocked you can also run
(also handy for checking what is actually meant to be mapped where).
Another way of doing this that leaves the system
auto.master untouched is to create a file
/etc/auto.master.d/opt.autofs (the first part of the name can be anything you want). Put the same contents in the file, e.g.
Note that using this mechanism normally requires two files – one in
/etc/auto.master.d/ and a map file that it refers to. In this case
-null is a built-in map.
Unfortunately this option is not well documented. Places where it is referred to are:
There are also other built-in maps, e.g.
-fedfs. Of these only the
-hosts map is documented in the
auto.master(5) man page.
-null is confirmed to work in CentOS 7, CentOS 8, Ubuntu 20.04, Debian 10.
After updating anything to use systemd-235 NIS logins either don’t work at all (usually for GUI logins), or take a long time to login (console or ssh, sometimes). The culprit is a line in the
This sandboxes the service and doesn’t allow it to talk to the network. Unfortunately this affects nis lookups done via the glibc NSS API. See the links at https://github.com/systemd/systemd/pull/7343
The quick solution is to turn off the sandboxing, either by commenting out or changing the line in systemd-logind.service, or creating a drop-in snippet that overrides it. This can be done by creating a file
/etc/systemd/system/systemd-logind.service.d/IPAddress_clear.conf with the contents:
The file can be called anything you like (
Then restart things:
systemctl restart systemd-logind.service
You can check that the drop-in is being loaded with
systemctl status systemd-logind.service
In the output you should see something like:
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
The other test is to see if NIS logins work correctly, of course…
The slightly slower solution is to use
nscd to cache the lookup requests, and apparently does so in a way that plays nicely with the sandboxing. The much slower solution is to switch to using
sssd or similar and ditch NIS once and for all…
Note – this may also affect
See the guide for 16.04, but with the following caveats:
Looks like you still need to add nis explicitly to
rpcbind service issue appears to be fixed.
Note – this only sets up the system to use user and group logons, not automounting home directories. I haven’t figured out how to make this work in Ubuntu 16.
Probably a good idea to set network address statically in
/etc/network/interfaces (NetworkManager should recognise this and then leave it alone)
Probably also a good idea to check that
/etc/hosts has the domain name for the system, i.e.
127.0.1.1 domain.name.machinename machinename
Add yp server to
/etc/nsswitch.conf to add nis for passwd, group and shadow. Note that compat should include nis by default.
Add a dependency to make the rpcbind service start at boot
systemctl add-wants multi-user.target rpcbind.service
(See this Debian bug report or this Ubuntu one)
Note that this is not a complete fix – it is reported that if the network does not come up fast enough things still break.
For users that need to log on to the system, create home directories
Remember to reboot to check everything is working:
if that fails check if the bind services are running
systemctl status rpcbind
systemctl status ypbind