Your message dated Thu, 24 Nov 2022 23:46:23 +0100 with message-id <Y3/[email protected]> 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 [email protected] immediately.) -- 864398: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864398 Debian Bug Tracking System Contact [email protected] 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 ---
