--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: nfs-common: can't mount nfs3 after updating to nfs-common 1:1.3.4-2.1
- From: Selene Scriven <debian@toykeeper.net>
- Date: Wed, 07 Jun 2017 19:49:31 -0600
- Message-id: <149688657114.12510.5068905168489622477.reportbug@banana.xyzz.org>
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 ---
- To: Selene Scriven <debian@toykeeper.net>, 864398-done@bugs.debian.org
- Subject: Re: Bug#864398: nfs-common: can't mount nfs3 after updating to nfs-common 1:1.3.4-2.1
- From: Salvatore Bonaccorso <carnil@debian.org>
- Date: Thu, 24 Nov 2022 23:46:23 +0100
- Message-id: <Y3/0P6B66P5fIoBa@eldamar.lan>
- In-reply-to: <149688657114.12510.5068905168489622477.reportbug@banana.xyzz.org>
- References: <149688657114.12510.5068905168489622477.reportbug@banana.xyzz.org>
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 ---