[Bug 1970264] Re: autofs fails to mount nfs4 shares with "error 0x3 getting portmap client"
Jens Elkner
1970264 at bugs.launchpad.net
Sat Aug 13 00:48:18 UTC 2022
And yes, setting `[ autofs ] mount_nfs_default_protocol = 4` in
/etc/autofs.conf doesn't fix the problem either.
Same thing wrt. `[ NFSMount_Global_Options ] vers=4 nfsvers=4
defaultvers=4` of /etc/nfsmount.conf.
Very confusing all the different files ...
--
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 Released
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
More information about the foundations-bugs
mailing list