Bug#914820: marked as done (nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start)

To: Salvatore Bonaccorso <carnil@debian.org>
Subject: Bug#914820: marked as done (nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start)
From: "Debian Bug Tracking System" <owner@bugs.debian.org>
Date: Tue, 14 Sep 2021 18:00:07 +0000
Message-id: <[🔎] handler.914820.D914820.16316422005771.ackdone@bugs.debian.org>
Reply-to: 914820@bugs.debian.org
References: <[🔎] YUDiUsQUCTY7OJNg@eldamar.lan> <20181127171951.GK3695@bitfolk.com>

Your message dated Tue, 14 Sep 2021 19:56:34 +0200
with message-id <[🔎] YUDiUsQUCTY7OJNg@eldamar.lan>
and subject line Re: Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
has caused the Debian Bug report #914820,
regarding nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
914820: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914820
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

--- Begin Message ---

To: submit@bugs.debian.org
Subject: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
From: Andy Smith <andy@strugglers.net>
Date: Tue, 27 Nov 2018 17:19:51 +0000
Message-id: <20181127171951.GK3695@bitfolk.com>

Package: nfs-kernel-server
Version: 1:1.3.4-2.1
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?

Upgrading a Debian jessie host to stretch and using systemd unit file
/lib/systemd/system/nfs-server.service instead of SysV init script
/etc/init.d/nfs-kernel-server

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Started nfs-server unit while having paths in the /etc/exports that do
not exist locally.

   * What was the outcome of this action?

The exportfs exit status was propagated to the unit due to direct use of
exportfs in ExecStartPre, so the unit failed to start.

   * What outcome did you expect instead?

To see the exportfs errors as usual, but for the NFS server to still
start up. This was the behaviour with the previous release's SysV init
script.

While I can see that it might be bad practice to have paths in the
/etc/exports file that don't exist locally, I thought these were more
like warnings from exportfs, not something that should prevent the whole
NFS server from working.

I have multiple NFS servers and I regarded it as harmless to have one
common /etc/exports file for all of them. Now I need to make them
host-specific. Also it seems like a bit of a surprise that you can
cripple a whole NFS server's next start just by deleting a directory
that is in /etc/exports.

While I do make them host-specific, and make sure they are altered when
any of their entries get removed (which will require changes to my
configuration management), I deployed this hack:

$ diff -Naur /{lib,etc}/systemd/system/nfs-server.service
--- /lib/systemd/system/nfs-server.service      2017-03-20 15:07:55.000000000 +0000
+++ /etc/systemd/system/nfs-server.service      2018-11-20 20:41:51.185660347 +0000
@@ -26,13 +26,13 @@
 
 Type=oneshot
 RemainAfterExit=yes
-ExecStartPre=/usr/sbin/exportfs -r
+ExecStartPre=/bin/sh -c "/usr/sbin/exportfs -r || true"
 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
 ExecStop=/usr/sbin/rpc.nfsd 0
-ExecStopPost=/usr/sbin/exportfs -au
-ExecStopPost=/usr/sbin/exportfs -f
+ExecStopPost=/bin/sh -c "/usr/sbin/exportfs -au || true"
+ExecStopPost=/bin/sh -c "/usr/sbin/exportfs -f || true"
 
-ExecReload=/usr/sbin/exportfs -r
+ExecReload="/bin/sh -c "/usr/sbin/exportfs -r || true"
 
 [Install]
 WantedBy=multi-user.target


-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  32766  mountd
    100005    1   tcp  32766  mountd
    100005    2   udp  32766  mountd
    100005    2   tcp  32766  mountd
    100005    3   udp  32766  mountd
    100005    3   tcp  32766  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049
    100021    1   udp  59762  nlockmgr
    100021    3   udp  59762  nlockmgr
    100021    4   udp  59762  nlockmgr
    100021    1   tcp  37581  nlockmgr
    100021    3   tcp  37581  nlockmgr
    100021    4   tcp  37581  nlockmgr
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids --port 32766"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=
-- /etc/exports --
/data/backup/rsnapshot/hourly.0/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.1/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.2/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.3/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.4/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/hourly.5/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.0/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.1/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.2/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.3/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.4/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.5/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/daily.6/192.168.82.121     192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.0/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.1/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.2/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/weekly.3/192.168.82.121    192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.0/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.1/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.2/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.3/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.4/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
/data/backup/rsnapshot/monthly.5/192.168.82.121   192.168.82.121(sync,ro,no_root_squash,no_subtree_check)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs
/data/backup/rsnapshot/hourly.0/192.168.82.121	192.168.82.121(ro,no_root_squash,sync,wdelay,no_subtree_check,uuid=b43be141:50e8498f:ae68c514:1e2fc792,sec=1)

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nfs-kernel-server depends on:
ii  init-system-helpers  1.48
ii  keyutils             1.5.9-9
ii  libblkid1            2.29.2-1+deb9u1
ii  libc6                2.24-11+deb9u3
ii  libcap2              1:2.25-1
ii  libsqlite3-0         3.16.2-5+deb9u1
ii  libtirpc1            0.2.5-1.2+deb9u1
ii  libwrap0             7.6.q-26
ii  lsb-base             9.20161125
ii  netbase              5.4
ii  nfs-common           1:1.3.4-2.1
ii  ucf                  3.0036

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

--- End Message ---

--- Begin Message ---

To: Andy Smith <andy@strugglers.net>, 914820-done@bugs.debian.org

Cc: submit@bugs.debian.org

Subject: Re: Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start

From: Salvatore Bonaccorso <carnil@debian.org>

Date: Tue, 14 Sep 2021 19:56:34 +0200

Message-id: <[🔎] YUDiUsQUCTY7OJNg@eldamar.lan>

In-reply-to: <20181127171951.GK3695@bitfolk.com>

References: <20181127171951.GK3695@bitfolk.com>
Source: nfs-utils
Source-Version: 1:2.5.4-1~exp1 

Upstream commit 003000d45183 ("exportfs: Ingnore export failures in
nfs-server.serivce unit") addresses this issue.

Regards,
Salvatore
--- End Message ---

Reply to:

References:
- Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
  - From: Salvatore Bonaccorso <carnil@debian.org>

Prev by Date: Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
Next by Date: Processed: closing 514910
Previous by thread: Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
Next by thread: Processed: closing 514910
Index(es):
- Date
- Thread