Your message dated Thu, 24 Nov 2022 23:46:23 +0100
with message-id <Y3/0p6b66p5fi...@eldamar.lan>
and subject line Re: Bug#864398: nfs-common: can't mount nfs3 after updating to
nfs-common 1:1.3.4-2.1
has caused the Debian Bug report #864398,
regarding nfs-common: can't mount nfs3 after updating to nfs-common 1:1.3.4-2.1
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 ow...@bugs.debian.org
immediately.)
--
864398: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864398
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: nfs-common
Version: 1:1.3.4-2.1
Severity: important
Dear Maintainer,
It looks like something somewhat recent in testing broke the nfs3 client.
* What led up to the situation?
After updating from stable to testing, I could not mount nfs3
shares. Typical results were pretty opaque:
$ mount /mnt/shared
mount.nfs: mount system call failed
There is no firewall; iptables -L shows no rules at all. It
appears that rpcbind and rpc.statd are both running. The nfs
server works for other clients, and worked for this client before
updating.
* What exactly did you do (or not do) that was effective (or
ineffective)?
While looking for relevant bugs, I found mentions of
systemd-related problems, including nfs-common.service being
masked (which it was).
First I asked apt to downgrade nfs-common and rpcbind to the stable
version, but it complained it would need to remove systemd. So I
found some intermediate-version systemd packages cached on another
host and downgraded to match what it has.
To get nfs3 working again, I downgraded several packages:
downgrading systemd from 232-25 to 229-4
downgrading libsystemd0:amd64 from 232-25 to 229-4
downgrading udev from 232-25 to 229-4
downgrading libudev1:amd64 from 232-25 to 229-4
downgrading libpam-systemd:amd64 from 232-25 to 229-4
downgrading rpcbind from 0.2.3-0.6 to 0.2.1-6.1
downgrading nfs-common from 1:1.3.4-2.1 to 1:1.2.8-9
Since these had to be downgraded as a set, I'm not sure exactly
which package(s) are responsible. It also doesn't narrow down the
nature of the error, but it does at least reduce things to a
specific range of versions. I don't see packages available for
intermediate versions though, so I haven't found a more specific
revision to check.
* What was the outcome of this action?
Upgrading from stable (jessie) to testing broke nfs3; I couldn't
mount remote filesystems from /etc/fstab or from a command line.
Downgrading a few packages back to stable (or an earlier version
from testing, in some cases) got nfs3 working again.
* What outcome did you expect instead?
In general, nfs is something which usually "just works", using the
following steps:
- Do a minimal install.
- (optional) add debian/testing to sources.list and
apt upgrade/dist-upgrade to it
- apt install nfs-common
- mkdir /mnt/path ; mount server:/path /mnt/path
Something in testing is breaking this use case.
I'm sorry I don't have more specifics...
The information below is from after I got it working.
-- 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
100024 1 udp 33146 status
100024 1 tcp 50201 status
-- /etc/default/nfs-common --
NEED_STATD=yes
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nas:/volume1/shared /mnt/shared nfs
user,nolock,intr,rsize=8192,wsize=8192,exec 0 0
-- /proc/mounts --
nas:/volume1/shared /mnt/shared nfs
rw,nosuid,nodev,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.5.5.4,mountvers=3,mountport=892,mountproto=udp,local_lock=all,addr=10.5.5.4
0 0
-- System Information:
Debian Release: 9.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nfs-common depends on:
ii adduser 3.115
ii initscripts 2.88dsf-59.9
ii libc6 2.24-11
ii libcap2 1:2.25-1
ii libcomerr2 1.43.4-2
ii libdevmapper1.02.1 2:1.02.137-2
ii libevent-2.0-5 2.0.21-stable-3
ii libgssapi-krb5-2 1.15-1
ii libk5crypto3 1.15-1
ii libkeyutils1 1.5.9-9
ii libkrb5-3 1.15-1
ii libmount1 2.29.2-1
ii libnfsidmap2 0.25-5.1
ii libtirpc1 0.2.5-1.2
ii libwrap0 7.6.q-26
ii lsb-base 9.20161125
ii rpcbind 0.2.1-6.1
ii ucf 3.0036
Versions of packages nfs-common recommends:
ii python 2.7.13-2
Versions of packages nfs-common suggests:
pn open-iscsi <none>
pn watchdog <none>
-- Configuration Files:
/etc/default/nfs-common changed [not included]
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Selene,
On Wed, Jun 07, 2017 at 07:49:31PM -0600, Selene Scriven wrote:
> Package: nfs-common
> Version: 1:1.3.4-2.1
> Severity: important
>
> Dear Maintainer,
>
> It looks like something somewhat recent in testing broke the nfs3 client.
>
> * What led up to the situation?
>
> After updating from stable to testing, I could not mount nfs3
> shares. Typical results were pretty opaque:
>
> $ mount /mnt/shared
> mount.nfs: mount system call failed
>
> There is no firewall; iptables -L shows no rules at all. It
> appears that rpcbind and rpc.statd are both running. The nfs
> server works for other clients, and worked for this client before
> updating.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> While looking for relevant bugs, I found mentions of
> systemd-related problems, including nfs-common.service being
> masked (which it was).
>
> First I asked apt to downgrade nfs-common and rpcbind to the stable
> version, but it complained it would need to remove systemd. So I
> found some intermediate-version systemd packages cached on another
> host and downgraded to match what it has.
>
> To get nfs3 working again, I downgraded several packages:
> downgrading systemd from 232-25 to 229-4
> downgrading libsystemd0:amd64 from 232-25 to 229-4
> downgrading udev from 232-25 to 229-4
> downgrading libudev1:amd64 from 232-25 to 229-4
> downgrading libpam-systemd:amd64 from 232-25 to 229-4
> downgrading rpcbind from 0.2.3-0.6 to 0.2.1-6.1
> downgrading nfs-common from 1:1.3.4-2.1 to 1:1.2.8-9
>
> Since these had to be downgraded as a set, I'm not sure exactly
> which package(s) are responsible. It also doesn't narrow down the
> nature of the error, but it does at least reduce things to a
> specific range of versions. I don't see packages available for
> intermediate versions though, so I haven't found a more specific
> revision to check.
>
> * What was the outcome of this action?
>
> Upgrading from stable (jessie) to testing broke nfs3; I couldn't
> mount remote filesystems from /etc/fstab or from a command line.
>
> Downgrading a few packages back to stable (or an earlier version
> from testing, in some cases) got nfs3 working again.
>
> * What outcome did you expect instead?
>
> In general, nfs is something which usually "just works", using the
> following steps:
>
> - Do a minimal install.
> - (optional) add debian/testing to sources.list and
> apt upgrade/dist-upgrade to it
> - apt install nfs-common
> - mkdir /mnt/path ; mount server:/path /mnt/path
>
> Something in testing is breaking this use case.
> I'm sorry I don't have more specifics...
>
>
> The information below is from after I got it working.
In the sense of BTS housekeeping I'm closing this old bugreport. If
you are still able to reproduce the issue on recent systems, can you
please reopen the bug so we might re-iterate through it?
Regards,
Salvatore
--- End Message ---