[Bug 1970264] Re: autofs fails to mount nfs4 shares with "error 0x3 getting portmap client"

Wed May 4 18:49:56 UTC 2022

On Wednesday, May 04 2022, Michael Kiermaier wrote:

> Thanks you for the detailed response.
>
> I have to say that this was the first time that I was confronted with
> the 'proposed'-repository. I followed the instructions at
> https://wiki.ubuntu.com/Testing/EnableProposed without too much
> investigation of the precise effect of the single steps.
>
> Thereby, I entered the lines
>
> cat <<EOF >/etc/apt/preferences.d/proposed-updates
> # Configure apt to allow selective installs of packages from proposed
> Package: *
> Pin: release a=$(lsb_release -cs)-proposed
> Pin-Priority: 400
> EOF
>
> which indeed pinned the autofs-ldap package, as you conjectured.
>
> Now I've added
> #apt-get install autofs-ldap/jammy-proposed
> and finally everything works as expected.
>
> Many thanks for your help!

Awesome!  Thank you for confirming.  Feel free to adjust the tags in the
bug to reflect the fact that you've verified that the fix works; this
will allow the package to migrate to the -updates repository after the
7-day grace period has passed.

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to autofs in Ubuntu.
https://bugs.launchpad.net/bugs/1970264

Title:
  autofs fails to mount nfs4 shares with "error 0x3 getting portmap
  client"

Status in autofs package in Ubuntu:
  Fix Released
Status in autofs source package in Jammy:
  Fix Committed
Status in autofs source package in Kinetic:
  Fix Released

Bug description:
  [ Impact ]

  NFSv4-only shares cannot be automounted if the server isn't running
  (or is blocking) rpcbind, even though NFSv4 doesn't require rpcbind
  anymore.

  [ Test Plan ]

  You will two Jammy VMs (unfortunately lxd VMs won't work, so you will
  likely need to use qemu/libvirt).  One will act as the NFSv4-only
  server, and the other will be the client with autofs configured.

  Here are the steps to configure the server VM:

  Install the NFS server:

  # apt install -y nfs-kernel-server

  Then, edit the nfs-server.service file:

  # systemctl edit --full nfs-server.service

  Remove any mentions to rpcbind.socket from the [Unit] section.  Also,
  edit the ExecStart line to look like:

  ExecStart=/usr/sbin/rpc.nfsd --no-nfs-version 3

  Stop and mask the rpcbind.* systemd units:

  # systemctl stop rpcbind.socket rpcbind.service
  # systemctl mask rpcbind.socket rpcbind.service

  Create a directory to share and export it:

  # mkdir /testshare
  # touch /testshare/testfile
  # echo -e '/testshare\t*(rw,sync,no_subtree_check)' >> /etc/exports

  Restart nfs-server:

  # systemctl restart nfs-server.service

  Here are the steps to configure the client VM:

  Install nfs-common and autofs:

  # apt install -y nfs-common autofs

  Add the automount configuration for the share (replace NFS_SERVER_IP
  with the IP address of the server VM you've just configured above):

  # echo -e '/mnt\t/etc/auto.nfs' >> /etc/auto.master
  # echo -e 'test\t-fstype=nfsv4\tNFS_SERVER_IP:/testshare' >> /etc/auto.nfs

  Restart autofs:

  # systemctl restart autofs.service

  Try to access the share and notice that it won't automount:

  # ls /mnt/test
  #

  You won't see any error messages unless you enable logging on autofs.
  To do that, uncomment the "logging" line on /etc/autofs.conf and set
  it to "debug".  You will then see something like the following when
  you run "journalctl -u autofs.service":

  get_portmap_client: error 0x3 getting portmap client
  mount(nfs): no hosts available

  You might also want to test an NFSv3 mount and make sure that it's still working as expected.  In order to do that, we have to reenable the rpcbind service in the server VM because NSFv3 requires it.

  Here are the instructions to test an NFSv3-only mount on the server
  VM:

  Re-enable rpcbind.{socket,service}:

  # systemctl unmask rpcbind.socket rpcbind.service
  # systemctl start rpcbind.socket rpcbind.service

  Edit the nfs-server.service:

  # systemctl edit --full nfs-server.service

  and change the ExecStart line to look like:

  ExecStart=/usr/sbin/rpc.nfsd --no-nfs-version 4

  Restart the service:

  # systemctl restart nfs-server.service

  Here are the instructions to test an NFSv3-only mount on the client VM:

  # echo -e 'test\t-fstype=nfs,nfsver=3\tNFS_SERVER_IP:/testshare' >
  /etc/auto.nfs

  (Remember to replace NFS_SERVER_IP with the IP address of the server
  VM)

  Restart autofs:

  # systemctl restart autofs.service

  Verify that the mount still works:

  # ls /mnt/test/
  test
  #

  [ Where problems could occur ]

  The patch that fixes the problem has been posted in the upstream
  mailing list by the maintainer, but hasn't been pushed to the git
  repository yet (although the maintainer said he would do this soon).
  I have carefully reviewed the patch and agree with the solution
  proposed; I have also verified that autofs' dep8 tests are still
  passing.  I find it unlikely that the patch introduces a problem.

  If a regression happens, it will most likely manifest during the
  automount process of NFSv4 shares.  We can mitigate the problem by
  suggesting the use of NFSv3 while we further investigate the issue,
  and, worst case scenario, we can revert the current fix and work with
  upstream to improve it.

  [ Original Description ]

  I'm running a server which provides user home directories as NFSv4
  shares. The clients mount these shares via automount + LDAP.

  Now I've updated one client from 20.04 to 22.04 (new installation from scratch). Setting up things as before, I cannot get the home directories to mount properly. The LDAP connection does work, and also manual mounting of the NFSv4 shares works. So the problem is in the automount part of the mechanism.
  The autofs package version on the 22.04 client is 5.1.8-1ubuntu1.

  Setting autofs to verbose mode, I get the following lines in /var/log/syslog on the client.
  automount[115692]: mount(nfs): nfs options="nfsvers=4,hard", nobind=0, nosymlink=0, ro=0
  automount[115692]: get_nfs_info: called with host <...> proto 6 version 0x40
  automount[115692]: get_portmap_client: error 0x3 getting portmap client
  automount[115692]: mount(nfs): no hosts available

  I think it is the same bug reported on the autofs mailing list here:
  https://www.spinics.net/lists/autofs/msg02389.html
  Apparently, it has been introduced in the transition of autofs from 5.1.7 to 5.1.8.

  A fix has been posted here:
  https://www.spinics.net/lists/autofs/msg02391.html

  It would be great if this fix could be included in Ubuntu 22.04, such
  that I can update my clients. As my setup should not be too exotic, I
  guess there are other people who will face the same problem when they
  are doing the Ubuntu update to the new LTS version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1970264/+subscriptions