[BUG] nfs-utils 2.9.2: exportfs link failure with --disable-nfsdctl

Jaipaul Cheernam <[email protected]> Wed, 5 Aug 2026 09:32:35 +0200
Newsgroups gmane.linux.nfs
Message-ID <[email protected]>
Hi,

   Building nfs-utils 2.9.2 with --disable-nfsdctl fails to link
   exportfs. This is a regression from 2.9.1.

   Reproducer:

   tar xf nfs-utils-2.9.2.tar.xz
   cd nfs-utils-2.9.2
   ./configure --disable-nfsdctl --disable-gss --disable-svcgss
   make

   (--disable-gss is just to avoid the krb5 dependency; the bug is
   triggered by --disable-nfsdctl alone.)

   Error:

   /usr/bin/ld: exportfs-exportfs.o: in function `unexportfs_parsed':
   exportfs.c:491: undefined reference to `nfsd_nl_cmd_str'
   collect2: error: ld returned 1 exit status

   Root cause:

   nfsdnl.c (new in 2.9.2) provides nfsd_nl_cmd_str() and is compiled
   into libnfs only under if CONFIG_NFSDCTL in support/nfs/Makefile.am.
   But exportfs.c calls it under #ifdef HAVE_NFSD_NETLINK, which
   configure.ac defines unconditionally:

   AC_DEFINE([HAVE_NFSD_NETLINK], 1,
             [Define to 1 if nfsd generic netlink support is available])

   So exportfs always compiles the netlink code path, but the
   implementation isn't linked in when --disable-nfsdctl is used.

   This isn't triggered with the default configuration because
   enable_nfsdctl defaults to "yes".

   Possible fixes:

   Option A — always compile nfsdnl.c into libnfs (remove the
   CONFIG_NFSDCTL guard from support/nfs/Makefile.am). exportfs would
   always have netlink unlock-export support. libnl is already
   unconditionally required so this adds no new dependency:

   --- a/support/nfs/Makefile.am
   +++ b/support/nfs/Makefile.am
   @@ -11,14 +11,10 @@
    libnfs_la_LIBADD = libnfsconf.la -luuid
    libnfs_la_CPPFLAGS = $(AM_CPPFLAGS) $(CPPFLAGS) 
-I$(top_srcdir)/support/reexport

   -if CONFIG_NFSDCTL
    libnfs_la_SOURCES += nfsdnl.c
   -libnfs_la_CPPFLAGS += $(LIBNL3_CFLAGS) $(LIBNLGENL3_CFLAGS) \
   -         -I$(top_srcdir)/utils/nfsdctl
   +libnfs_la_CPPFLAGS += $(LIBNL3_CFLAGS) $(LIBNLGENL3_CFLAGS)
    libnfs_la_LIBADD += $(LIBNL3_LIBS) $(LIBNLGENL3_LIBS)
   -endif

    libnfsconf_la_SOURCES = conffile.c xlog.c

   Option B — gate HAVE_NFSD_NETLINK on --enable-nfsdctl, so exportfs
   skips the netlink path when nfsdctl is disabled. nfsdnl.h already
   provides a static inline stub returning -ENOSYS for this case:

   --- a/configure.ac
   +++ b/configure.ac
   @@ -256,8 +256,6 @@
    PKG_CHECK_MODULES(LIBNLGENL3, libnl-genl-3.0 >= 3.1)

    AC_CHECK_HEADERS(linux/nfsd_netlink.h)
   -AC_DEFINE([HAVE_NFSD_NETLINK], 1,
   -   [Define to 1 if nfsd generic netlink support is available])

    # ensure the system netlink headers have the latest features
  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <linux/nfsd_netlink.h>]],
   @@ -279,6 +277,8 @@
     enable_nfsdctl="yes")
     AM_CONDITIONAL(CONFIG_NFSDCTL, [test "$enable_nfsdctl" = "yes" ])
     if test "$enable_nfsdctl" = yes; then
   +   AC_DEFINE([HAVE_NFSD_NETLINK], 1,
   +       [Define to 1 if nfsd generic netlink support is available])
       PKG_CHECK_MODULES(LIBREADLINE, readline)
     fi


   Both build cleanly. I lean towards Option B as it preserves the design
   intent that --disable-nfsdctl disables all netlink interaction with
   nfsd, and keeps the feature gating consistent between configure.ac and
   Makefile.am. But Option A has merit if exportfs should always release
   state via netlink regardless of whether the nfsdctl utility is built.

   Which approach is preferred? Happy to send a formal patch either way.

   Thanks,
   Jaipaul