Ubuntu – NFS4: 18.04 Client : force NFS ver=4.0 ? (ldap map, multiple client versions)

18.04ldapmountnfs

autofs map via LDAP.
NFS4 – Server: Ubuntu 10.04
NFS4 – Clients: Ubuntu 10.04, 14.04, 18.04

To mount a NFS4 resource of a 10.04-server to a 18.04-client mount-option "vers=4.0" is required. Otherwise the client only tries 4.2 and 4.1 and then gives up.

This mount-option "vers=4.0" is however not understood by 10.04 – clients so that I can not change the common ldap-based autofs-map.

How can I force the client to use "vers=4.0" ? There is a variable "MOUNT_NFS_DEFAULT_PROTOCOL" in /etc/default/autofs. But it is apparentely only ment to distinguisch between "3" and "4", not between "4.0" and "4.1"

Thanks for any idea.

Best Answer

Use an OpenLDAP translucent proxy overlay

You could set up an OpenLDAP server on top of the existing one, using the slapo-translucent overlay. With this overlay you can proxy all requests to your existing ldap server, but override certain attributes with local values.

So you would make your main ldap server contain the mount options most clients can understand, and then, in the overlay ldap server, rewrite the automountInformation attribute to not contain the vers=4.0 mount option and make your 10.04 clients use this other server. Every other attribute should be handled transparently by the overlay and sent back to your main ldap.

Related Solutions

Ubuntu – Setup for mounting kerberized nfs home directory – gssd not finding valid kerberos ticket

See this thread:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190267

If there is no "user" option in fstab, only root can mount volumes. There is some comment in mount.c on making the mount command executable by any user, but that was rejected by the maintainer (the comment says something about security implications, but is not more specific).

In contrast to the original upstream, the Debian version of libpam-mount executes mount commands with the user uid, not as root. Doing user-specified mounts as root is a security hole. Any user then could mount a volume to /usr or /tmp on login, or umount any other volume on logout.

Or in other words libpam-mount can do only things the user can do, nothing more.

So, any suggestions?

Putting a user entry in fstab should do it. Please tell me how this works. Note that other filesystems (ncp, smb) have user-callable mount binaries like smbmount or ncpmount. There seems nothing like this for loopback mounts :/

Ubuntu – Unable to ping 18.04 desktop unless this machine first pings the client, when using networkd instead of network-manager

After realising I was affected by this bug and correcting for it, I found that networkctl showed the wireless interface as 'configuring' status.

I then found that NetworkManager was running, and on stopping it via sudo systemctl stop NetworkManager, followed by sudo systemctl restart systemd-networkd, and finally deleting the ARP entry on my Windows client before pinging again, everything worked. I did sudo systemctl disable NetworkManager and restarted to make sure the solution persisted and it did not...

A kind soul in the Ubuntu IRC channel guided me to do:

sudo systemctl mask network-manager.service
sudo systemctl mask NetworkManager-dispatcher.service
sudo systemctl mask NetworkManager-wait-online.service

This resolved the issue and networkctl now shows the status of 'configured'. It appears network-manager and systemd-networkd were fighting over configuration of the wireless interface. I suspect that my understanding that network-manager would leave it alone would be correct if there was no configuration in /etc/NetworkManager/system-connections/ but haven't tested this theory - I'm just relieved it's resolved.

Best Answer

Use an OpenLDAP translucent proxy overlay

Related Solutions

Ubuntu – Setup for mounting kerberized nfs home directory – gssd not finding valid kerberos ticket

Ubuntu – Unable to ping 18.04 desktop unless this machine first pings the client, when using networkd instead of network-manager

Related Question