nfs-kernel-server fails: hostname "has non-inet addr" on boot, before eth0 comes up

Bug #806284 reported by John Gilmore
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

I upgraded my server to Natty and now the two directories that this server exports to various other machines on the network, do not get exported during an ordinary bootup. However, after startup, if I run "exportfs -av" on them, they export just fine.

/var/log/syslog shows:

  Jul 5 16:17:54 om exportfs[1585]: name1.frob.com has non-inet addr

  Jul 5 16:17:54 om exportfs[1585]: last message repeated 3 times

  Jul 5 16:17:54 om exportfs[1585]: name2.frob.com has non-inet addr

  Jul 5 16:17:54 om exportfs[1585]: name2.frob.com has non-inet addr

(I've replaced the actual names with name1.frob.com and name2.frob.com).

The problem appears to occur because NetworkManager is still in the process of bringing up the network interface (according to other interleaved syslog reports). These hostnames need DNS from another server to resolve them.

The root cause of the problem appears to be that Natty doesn't make the nfs-kernel-server service wait until the first Ethernet comes up. Thus, nfs-kernel-service can't resolve domain names in the /etc/exports file, and it produces this very confusing message and doesn't actually export the filesystems.

Ubuntu release: 11.04 (natty)
Version of nfs-utils: Installed: 1:1.2.2-4ubuntu5

Related programs: upstart, NetworkManager

Tags: upstart
Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 806284] [NEW] nfs-kernel-server fails: hostname "has non-inet addr" on boot, before eth0 comes up

On Wed, Jul 06, 2011 at 02:32:43AM -0000, John Gilmore wrote:
> The problem appears to occur because NetworkManager is still in the
> process of bringing up the network interface (according to other
> interleaved syslog reports). These hostnames need DNS from another
> server to resolve them.

> The root cause of the problem appears to be that Natty doesn't make the
> nfs-kernel-server service wait until the first Ethernet comes up. Thus,
> nfs-kernel-service can't resolve domain names in the /etc/exports file,
> and it produces this very confusing message and doesn't actually export
> the filesystems.

That's correct. The /etc/init/rc-sysinit.conf job waits for the loopback
interface to be up, but does not wait for other interfaces; this is
consistent with the historical guarantee provided by pre-upstart init
scripts on Ubuntu as well, but as boot becomes faster it's more common to
lose a race against the network.

Ultimately, nfs-kernel-server should switch to using a native upstart job,
and should probably be set to start on net-device-up IFACE!=lo by default.

Changed in nfs-utils (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

This seems oddly similar to bug #862928 , which states that it is about NetworkManager, but is really the same problem.

net-device-up IFACE!=lo is not sufficient. Some servers have many network interfaces, and the remote network services they provide should not be started until all of them are up.

On 11.10 and later, this is handled by the static-network-up event, which gates runlevel 2 (or at least, slows it down for 2 minutes until we kick off the failsafe boot). I wonder if this problem still exists on Ubuntu 11.10.

Revision history for this message
Daniel Moyne (daniel-moyne-free) wrote :

since installation of Ubuntu 20.04.3 LTS (Focal Fossa)20.04 nfs connection between client and server on my home lan is no more possible ; I removed autofs and firewall before using direct mount command on client with no success though the export check on server shows authorization ; everything has been done following the rules for client and server ; need help to recover proper access

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.