From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) Description of problem: Same problem as identified for Fedora Core in bug 112598 The problem is fixed by applying the suggested patch in bug report 112598: start and stop the kernel nfsd once before setting the TCP and UDP ports in /etc/init.d/nfs Version-Release number of selected component (if applicable): nfs-utils 1.0.6 21EL How reproducible: Always Steps to Reproduce: 1. set LOCKD_TCPPORT in /etc/sysconfig/nfs to a value, say 4001 2. reboot machine 3. check port associated with lockd: rpcinfo -p | grep nlockmgr Actual Results: 100021 1 udp 32770 nlockmgr Expected Results: 100021 1 udp 4001 nlockmgr Additional info: This bug prevents using the NFS server with a firewall!
This should be fixed in a later nfs-utils
As well as RHEL systems I manage a reasonable number of SuSE Pro based systems. I notice that in 9.1 they don't bother with assigning static ports to rpc services, instead they simply scan the ports (rpcinfo -p) to build a service-to-port mapping and then add firewall rules for the ports associated with selected services (FW_SERVICES_EXT_RPC in /etc/sysconfig/SuSEfirewall2). This is not only a more elegant solution but also solves the problem where an rpc service has no mechanism for binding to a specific port, such as sgi_fam.
I believe that you can force lockd to use particular ports by adding a line like the following to /etc/modules.conf: options lockd nlm_udpport=4001 nlm_tcpport=4001
My point is that, out of the box, RHEL3 has a problem. There are a number of ways of fixing this bug - RedHat should test and implement one of them ASAP.
The modules.conf fix is confirmed to work as of 2.4.21-27.0.2 while the /etc/sysconfig/nfs solution would work as of 2.4.21-15.EL so something changed between those kernel versions.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.