Bug#739721: systemd: NFS shares are not automatically mounted during boot

[Ian Campbell]

Control: reopen -1
Control: found -1 215-5+b1

On Sun, 14 Sep 2014 17:20:47 +0200 Michael Biebl <biebl at debian.org> wrote:
> I'm going to close this bug for now. If you still encounter any issues
> and you have additional information, please let us know, so we can
> reopen the bug report.

I'm seeing this issue and it seems that others have added more info
since the bug was closed here, hence reopening as suggested.

For my part I'm seeing it on an up to date Jessie system (apt upgrade
this morning) talking to a Wheezy server.

My /etc/network/interfaces is:
        # The loopback network interface
        auto lo
        iface lo inet loopback
        
        # The primary network interface
        auto eth0
        iface eth0 inet dhcp

My /etc/fstab contains:
        filer01:/srv/exports/music	/storage/music		nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys
        filer01:/srv/exports/media	/storage/media		nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys
        filer02:/srv/exports/mythvideo	/var/lib/mythvideo	nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5
        filer02:/srv/exports/mythtv	/var/lib/mythtv/recordings nfs defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5

On most boots some subset of these do not come up. Before the apt
upgrade this morning I was running 208-8 and the failure was only
intermittent. Since updating to 215-5+b1 I've been seeing at least one
of the mounts failing on each boot. On failure I see:

        # systemctl status -l var-lib-mythtv-recordings.mount 
        ● var-lib-mythtv-recordings.mount - /var/lib/mythtv/recordings
           Loaded: loaded (/etc/fstab)
           Active: failed (Result: exit-code) since Sun 2014-10-19 12:35:04 BST; 3min 53s ago
            Where: /var/lib/mythtv/recordings
             What: filer02:/srv/exports/mythtv
             Docs: man:fstab(5)
                   man:systemd-fstab-generator(8)
          Process: 428 ExecMount=/bin/mount -n filer02:/srv/exports/mythtv /var/lib/mythtv/recordings -t nfs -o defaults,nosuid,intr,rsize=32768,wsize=32768,nfsvers=3,tcp,sec=sys,actimeo=5 (code=exited, status=32)
        
        Oct 19 12:35:04 iranon rpc.statd[454]: Version 1.2.8 starting
        Oct 19 12:35:04 iranon rpc.statd[454]: Flags: TI-RPC
        Oct 19 12:35:04 iranon rpc.statd[454]: failed to create RPC listeners, exiting
        Oct 19 12:35:04 iranon mount[428]: mount.nfs: rpc.statd is not running but is required for remote locking.
        Oct 19 12:35:04 iranon mount[428]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
        Oct 19 12:35:04 iranon mount[428]: mount.nfs: an incorrect mount option was specified
        Oct 19 12:35:04 iranon systemd[1]: var-lib-mythtv-recordings.mount mount process exited, code=exited status=32
        Oct 19 12:35:04 iranon systemd[1]: Failed to mount /var/lib/mythtv/recordings.
        Oct 19 12:35:04 iranon systemd[1]: Unit var-lib-mythtv-recordings.mount entered failed state.

The output is essentially identical in each case.

Running "mount -a" lets everything come up.

rpcbind seems to be running:
        # systemctl status -l rpcbind.service 
        ● rpcbind.service - LSB: RPC portmapper replacement
           Loaded: loaded (/etc/init.d/rpcbind)
          Drop-In: /run/systemd/generator/rpcbind.service.d
                   └─50-rpcbind-$portmap.conf
           Active: active (running) since Sun 2014-10-19 12:35:04 BST; 4min 29s ago
          Process: 434 ExecStart=/etc/init.d/rpcbind start (code=exited, status=0/SUCCESS)
           CGroup: /system.slice/rpcbind.service
                   └─460 /sbin/rpcbind -w
        
        Oct 19 12:35:04 iranon rpcbind[434]: Starting rpcbind daemon....

The timestamps are very close to the mounts -- so perhaps a race? That
fits in with the observation in message #77 that this is related to
portmap (AIUI rpcbind is the new portmap).

Looking over the bug I think I've supplied the sort of information
you've generally been looking for, if there's anything else you need
though just give a shout.

Cheers,
Ian.