NFSv3 Daemon not using user-specified ports

[outofspace]

I am using NFSv3 for server to server data shares, and I wanted to avoid the absolute disaster that is the default port selection of NFS ( I actually care about creating properly locked down firewall rules).

I listed very specific ports in the NFS service section in the GUI.

Unfortunately, it appears that the rpc port mapper is still serving random high ports for clients to connect to, which is absolutely unacceptable.
It appears NFS is listening on the port (cannot confirm what program, even as root).

Client (Debian 11) trying to connect to the RHP:

I've remounting from the client, restarting the client, restarting truenas, and restarting the NFS service on truenas.
All of that only resulted in the RHP that the client tries to connect to being changed to another RHP (this is the unacceptable part...)

So, couple of questions:
Why? Is there another hidden NFS config that the GUI doesnt allow configuration of?
Is it possible to change whatever subprocess of NFS this port is serving?
And if its possible, How (wheres the file) can I change the port?


I do have to say I am not using NFSv4 because of the huge performance hit for low latency single connections.

Update: rpcinfo -p
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
100005 3 udp 2050 mountd
100005 3 tcp 2050 mountd
100003 3 tcp 2049 nfs
100227 3 tcp 2049
100021 1 udp 54513 nlockmgr
100021 3 udp 54513 nlockmgr
100021 4 udp 54513 nlockmgr
100021 1 tcp 40301 nlockmgr
100021 3 tcp 40301 nlockmgr
100021 4 tcp 40301 nlockmgr

So I guess my actual question is how do I change the nlockmgr port?

 

[outofspace]

I'll admit I got a bit emotional there and jumped the gun, found the answer myself.

Change /etc/sysctl.conf and add following lines
fs.nfs.nlm_udpport=2052
fs.nfs.nlm_tcpport=2052
then run sysctl -p or reboot

Fixed my issue, but it still doesn't excuse the fact the GUI config straight up ignored the ports I specified for rpc.statd and rpc.lockd....

 

[morganL]

I'll admit I got a bit emotional there and jumped the gun, found the answer myself.

Change /etc/sysctl.conf and add following lines
fs.nfs.nlm_udpport=2052
fs.nfs.nlm_tcpport=2052
then run sysctl -p or reboot

Fixed my issue, but it still doesn't excuse the fact the GUI config straight up ignored the ports I specified for rpc.statd and rpc.lockd....

Haven't seen this need or issue before.... please "report-a-bug"
Have you or anyone else seen this working on CORE.... it might be a FreeBSD-to-Linux transition issue?
Or it might be an issue with late transition from NFS-Ganesha to NFS kernel.... I assume you are running SCALE 22.02.0?

 

[KrisBee]

@erasedhammer Don't worry about getting "emotional" re: NFS on SCALE, because IMHO it's a mess.

@morganL So far, these are the issues I'm aware of with the "late transition from NFS-Ganesha to NFS kernel" ,

No recognition that the "wheel" group with guid=0 in FeeBSD equates to "root" group in Linux.
No way to select proper Linux export options.
Bind ports doesn't work.
If you have a fresh instance of SCALE and try to configure/start the NFS service it fails, because there is no dummy export file and the relevant systemd units fail.
No way to operate server in pure NFSv4 mode without rpc.bind if you really wanted to do that.

 

[morganL]

@erasedhammer Don't worry about getting "emotional" re: NFS on SCALE, because IMHO it's a mess.

@morganL So far, these are the issues I'm aware of with the "late transition from NFS-Ganesha to NFS kernel" ,

No recognition that the "wheel" group with guid=0 in FeeBSD equates to "root" group in Linux.
No way to select proper Linux export options.
Bind ports doesn't work.
If you have a fresh instance of SCALE and try to configure/start the NFS service it fails, because there is no dummy export file and the relevant systemd units fail.
No way to operate server in pure NFSv4 mode without rpc.bind if you really wanted to do that.

Thanks for the list. It was a late change due to inability to get Ganesha stable enough. I'll check in with engineering team to work through the list and the schedule for fixes.