Description of problem: This is an old problem identified in nfs-utils v1.2.3 in October 2010. When the configuration file /etc/sysconfig/nfs-server contains the line RPCMOUNTD_OPTIONS="--port 4003" then a client attempting to connect to the server will get an error. The RPCMOUNTD_OPTIONS option is set when selecting NFS Server in the allowed connections list in the MCC Personal Firewall configuration page. Version-Release number of selected component (if applicable): 1.2.3-2.1.mga1 How reproducible: Repeatable. Steps to Reproduce: 1. Disable personal firewall (Shorewall) 2. Install nfs-utils 3. observe that /etc/sysconfig/nfs-server has a line; RPCMOUNTD_OPTIONS= 4. configure a share 5. successfully connect from a remote client then unmount the share 6. Enable personal firewall (Shorewall) with hole for NFS server 7. observe that /etc/sysconfig/nfs-server has a line; RPCMOUNTD_OPTIONS="--port 4003" 8. try to connect from a remote client I have tested the proposed patch from Chuck Lever identified at https://bugzilla.linux-nfs.org/show_bug.cgi?id=190 by rebuilding nfs-utils-1.2.3-2.1.mga1.src.rpm with the patch and suitably modified spec file. I am running the server now through a personal firewall hole with the rpc.mountd port set to 4003 and it is just fine.
Keywords: (none) => PATCHAssignee: bugsquad => guillomovitch
I just submitted nfs-utils-1.2.3-2.2.mga2 to core/update_testing with the patch applied, please test and report. This problem apart, just some personal thought about using NFS and a firewall... First, NFS is a LAN protocol, genereally used in a trusted LAN. Running a firewall in such environment is plain overkill, in general. You'd better run a firewall between your LAN and internet, only only if really needed, rather than around each your machines. Second, if you really want to use a firewall, don't use old random-port NFS, but use NFSv4, which only use TCP port 2049 for everything, it's far easier to configure.
Status: NEW => ASSIGNED
nfs-utils-1.2.3-2.2.mga2 typo? I installed nfs-utils-1.2.3-2.2.mga1 and it now works with the fixed port option. On your First point, I cannot disagree with a word you say. I run Smoothwall between my LAN and my cable router. I was responding to a request for help with nfs on mageia-discuss when I stumbled on this issue. On your Second point, another responder in the same thread on mageia-discuss mentioned NFSv4 too. I have just checked that I do have Core Backports enabled on my MGA1 machine but there is no sign of a newer nfs-utils than 1.2.3. It is 1.2.6 that takes us to NFSv4, yes? I believe even Cauldron is still on 1.2.5, so perhaps 1.2.6 will show up there and in MGA1 backports soon. Thirdly, what you said about use of Shorewall in Mageia prompted me to take a closer look at the way the firewall "wizard" in MCC manages the changes it makes to affected server configurations - well, at least NFS. I note that whilst it will set the fixed port options for nfs (and coincidentally reveal the mount bug) it will not revert the change if you turn off the firewall. If this is a conscious decision then it is probably a little harsh to call it a bug, but if MGA1 and MGA2 are both likely to be using "old random-port NFS" for a while longer, should I raise this as an enhancement request for Shorewall control; that it should mark and revert its changes when it is disabled? Thanks for the fix - much appreciated. Richard
If it's ready for the QA, please reassign the bug. https://wiki.mageia.org/en/Updates_policy
Suggested advisory: The mountd binary was ignoring -p option, allowing to give a specific port to it, mainly in order to traverse firewalls. The nfs-utils-1.2.3-2.2.mga1 update package fixes this issue, using an upstream patch.
Assignee: guillomovitch => qa-bugs
I have no complaint with that.
Running Mageia 1 fully updated with updates testing on both host and a virtualbox guest. I've setup a share on the host, and I can mount it in the guest using mount 192.168.10.101:/ /host however I cannot see the share in mcc after selecting "search servers".
CC: (none) => davidwhodgins
Tested successfully on x86_64 Initially like Dave in Comment 6 scanning from remote clients mcc failed to find the nfs share. After restarting all the services relating to nfs (nfs-common, nfs-mount-export, nfs-server) the remote client was able to find the share. Verified that with the hole for nfs in shorewall the remote client can mount and unmount nfs shares. Packages tested nfs-utils-clients-1.2.3-2.2.mga1 and nfs-utils-1.2.3-2.2.mga1
CC: (none) => derekjenn
Figured out the problem was a reverse dns issue. Fixed now. Validating the update. Could someone from the sysadmin team push the srpm nfs-utils-1.2.3-2.2.mga1.src.rpm from Core Updates Testing to Core Updates. Advisory: This update to nfs-utils corrects an issue where rpc.mountd ignored the --port option, specified in /etc/sysconfig/nfs-server. https://bugs.mageia.org/show_bug.cgi?id=4889
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update pushed
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED