NFS V4 does not mount at system start

Bug #1807749 reported by imker
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Triaged
Undecided
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Hi,

i'm running a view Ubuntu 18.10 Clients on a Ubuntu 18.04 NFS V4 Server. I'm using Kerberos for user authentication and LDAP for user and group synchronisation.

The shares are added to the /etc/fstab on my clients and they should be mounted automatically at system boot. Here is an example line from fstab:
nfs.server:/users /home nfs4 sec=krb5i,soft,_netdev,auto 0 0

But after the system has booted and the Login-Screen appears the nfs shares are not mounted on the client. Attached to this bug, you can find an export of my journald entries from my last boot.

When I read this log carefully I find the following start order of relevant services:
Begin start nss_ldap (from line 822 on)
Begin start NetworkManager (from line 1198)
Get IP from DHCP (line 2542)
NetworkManager Online (line 2551)
Try to mount NFS Shares (from line 2253)
nss_ldap connected (line 2761)

As far as I understand my setup, I do not have DNS before nss_ldap is started. But since mounting the NFS shares needs DNS, the NFS mount sequence should start after nss_ldap is fully started.

Thanks for your help

Revision history for this message
imker (imker) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

> As far as I understand my setup, I do not have DNS before nss_ldap
> is started.

nss_ldap is not "started". It is a module which is loaded into the memory of processes that need to resolve user and group names; error messages in your log about nss_ldap are caused by attempts to look up usernames before your network is configured.

In general, if you want robust LDAP and Kerberos operation on a host in the face of possible network disconnection, it's recommended that you use the sssd package instead of using nss_ldap directly.

As for your NFS mount failure, it is quite possible that the NFS mount is being attempted at boot before DNS resolution is available. The relevant bits of output in this log file are:

Dez 10 18:07:03 barney systemd[1]: Started Network Manager Wait Online.
Dez 10 18:07:03 barney systemd[1]: Reached target Network is Online.
[...]
Dez 10 18:07:03 barney systemd[1]: home.mount: Directory /home to mount over is
not empty, mounting anyway.
Dez 10 18:07:03 barney systemd[1]: Mounting /home...
[...]
Dez 10 18:07:03 barney mount[1803]: mount.nfs4: Failed to resolve server nfs.server: Name or service not known
Dez 10 18:07:03 barney mount[1800]: mount.nfs4: Failed to resolve server nfs.server: Name or service not known

So the issue is that network-manager is reporting to systemd that the network is "online", but DNS resolution of nfs.server still fails.

I believe this is a bug in the definition of NetworkManager-wait-online.service, which needs to block until not only packets can pass on an interface, but also DNS resolution works.

affects: nfs-utils (Ubuntu) → network-manager (Ubuntu)
Changed in network-manager (Ubuntu):
status: New → Triaged
tags: added: id-5c0edd402116a7823a36c543
tags: added: fr-631
Revision history for this message
Dan Streetman (ddstreet) wrote :

please reopen if this is still an issue

Changed in systemd (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.