Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234543 - RFE: Set static ports for NFS
Summary: RFE: Set static ports for NFS
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Dickson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-29 22:02 UTC by Forrest Taylor
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2007-0651
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-07 17:15:21 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0651 normal SHIPPED_LIVE nfs-utils bug fix and enhancement update 2007-10-30 16:19:49 UTC

Description Forrest Taylor 2007-03-29 22:02:04 UTC
Description of problem:  Ports for NFS are set dynamically by portmapper.  They
should be set statically.  Then we could easily use the firewall (iptables and
system-config-securitylevel) to allow those ports.

Version-Release number of selected component (if applicable):

Additional info:
Add this entry to /etc/sysconfig/nfs:


Comment 1 Steve Dickson 2007-04-21 12:26:34 UTC
Is there any log message in /var/log/messages as to why
all these daemons are failing to use the given ports?

Comment 2 Forrest Taylor 2007-05-08 03:00:30 UTC
They all work when I have the entries above.  I am requesting that we do this by
default.  Even creating the file with the entries commented out would be useful.

Comment 3 Steve Dickson 2007-05-08 10:53:45 UTC

Comment 4 RHEL Product and Program Management 2007-05-08 11:03:50 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 6 Steve Dickson 2007-05-12 12:52:40 UTC
Fixed in nfs-utils-1.0.9-18

Comment 7 Ville Skyttä 2007-05-16 17:33:44 UTC
Just a note, in nfs-utils-1.0.10-10.fc6, if one sets all the MOUNTD_NFS_V{1,2,3}
options to "no", mountd fails to start.  I tried that because I have no need for
< v4 NFS.

# /etc/init.d/nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd: Usage: rpc.mountd [-F|--foreground] [-h|--help]
[-v|--version] [-d kind|--debug kind]
        [-o num|--descriptors num] [-f exports-file|--exports-file=file]
        [-p|--port port] [-V version|--nfs-version version]
        [-N version|--no-nfs-version version] [-n|--no-tcp]
        [-H ha-callout-prog] [-s|--state-directory-path path]
        [-t num|--num-threads=num]

Comment 8 Steve Dickson 2007-05-16 18:14:28 UTC
hmmm... interesting... I do see your point wrt to not wanting to 
starti mountd when only v4 is needed... I would suspect lockd and statd are
in the same boat... and its not clear setting all version of mountd to
to no is the best way to deal with this... 

I would say this is a different problem so would you mind 
opening another bug about this? 

Comment 9 Kostas Georgiou 2007-05-16 23:57:56 UTC
The fedora6 update added /etc/sysconfig/nfs but without the noreplace option, I
suspect the rhel version does the same as well.

This means that if you have setup /etc/sysconfig/nfs already the changes are
lost, the server now listens to different ports which might be blocked by the
firewall, rpcgssd doesn't start since SECURE_NFS isn't defined and the sysadmin
has to lock the door to keep the angry crowds away.

Comment 10 Steve Dickson 2007-05-18 16:02:22 UTC
I made /etc/sysconfig/nfs a %config which will save the
file if and only if it changed. I did this so if I updated
the file with more variables, the file would actually
be installed, again, saving the old version.. 

I do see your point wrt to breaking an existing configuration
I'm not sure, at this point, what would be a better thing
to do... 

Comment 11 Kostas Georgiou 2007-05-18 16:28:51 UTC
This means that every time you update the file with new variables all the
changes that the sysadmin made are lost!. It is best to use noreplace which will
install the new file as /etc/sysconfig/nfs.rpmnew if the admin has made any
changes to the configuration.

Dropping all the changes every time there is an update is a very bad idea,
especially since the nfs server does restart after the update.

Comment 12 Forrest Taylor 2007-05-19 02:33:35 UTC
I think that the problem in this case was that the file did not exist previously
in the RPM.  Even though it was set as a %config it apparently overwrote the
file that didn't belong to any RPM.  In RHEL, we should probably use noreplace
for at least the initial push.

Comment 13 Forrest Taylor 2007-05-19 02:41:28 UTC
I just tested this on FC6.  It did move aside my current setting, but it did
save the file as nfs.rpmorig.  Now the NFS server is running on different ports
than it did previous to the update.

By the way, nice work on config file!  It is very well documented now.

Comment 14 Steve Dickson 2007-05-22 13:50:51 UTC
Agreed.... breaking configurations on updates is never a good
thing... plus it turns out an updated file will be installed
as a .rpmnew file (i.e. /etc/sysconfig/nfs.rpmnew) 

So I've updated the Fedora Core and RHEL nfs-utils.. 
(nfs-utils-1.0.9-19.el5 and nfs-utils-1.0.10-12.fc6)

Comment 18 errata-xmlrpc 2007-11-07 17:15:21 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.