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

Fri Apr 29 20:35:03 UTC 2022

** Description changed:

  [ 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 -la /mnt/test
+ # 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.

** Changed in: autofs (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: autofs (Ubuntu Kinetic)
   Importance: Undecided => High

-- 
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:
  In Progress
Status in autofs source package in Jammy:
  In Progress
Status in autofs source package in Kinetic:
  In Progress

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