Bug 533771 - system config nfs prepends (adds) an http:/ in front of host IP to be exported
system config nfs prepends (adds) an http:/ in front of host IP to be exported
Product: Fedora
Classification: Fedora
Component: system-config-nfs (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
: Triaged
: 530591 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-11-09 00:17 EST by Cia Watson
Modified: 2010-11-05 12:15 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-05 12:15:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Cia Watson 2009-11-09 00:17:48 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091027 Fedora/3.5.4-1.fc12 Firefox/3.5.4

When I added a share for NFS and entered the host IP; which wouldn't mount I opened to try changing a setting and discovered there was an http:/ in front of the host IP I'd entered, but I didn't enter the http:/. 

I opened the /etc/sysconfig/nfs file and discovered that indeed it was exporting with an http:/ in front of the host IP -- I removed the http:/ and then the mount worked. I removed the http from the host information in the system-config-nfs also, and then opened it again and discovered that there was now a 2nd entry for the hosts, apparently added by the software, that has the same IP with the http:/ added back in. 

Current output of /etc/exports is: 
cat /etc/exports
/mnt/data2share      ,insecure,sync),insecure,sync)

Reproducible: Always

Steps to Reproduce:
1. Open >system >administration >nfs
2. Add a share with host IP and other pertinent information 
3. Close application, re-open and discover an http:/ has been added to IP
Actual Results:  
an http:/ was prepended to the IP address for the host entered in the config. screen; therefore when it exported (exportfs) it can't be mounted by the host computer but results in an error message 'Permission denied'.

Expected Results:  
It leaves the IP address as entered.

Installed Packages
system-config-nfs.noarch                  1.3.49-1.fc12
Comment 1 Nils Philippsen 2009-11-10 05:44:17 EST
I can't reproduce this with system-config-nfs-1.3.49-1.fc12 -- in fact, there are only two "http://" strings in the code: the DTD URL in the glade files (which don't affect the running application).

I can't see how system-config-nfs would add "http://" to an IP or a host name at all. You mention /etc/sysconfig/nfs -- do you confuse that with /etc/exports or does it really contribute to the problem? I'm asking because the file only contains commentary per default.
Comment 2 Steve Dickson 2009-11-20 08:42:49 EST
*** Bug 530591 has been marked as a duplicate of this bug. ***
Comment 3 Cia Watson 2009-11-20 15:17:51 EST
Yes, I did mean /etc/exports. Sorry. There was an NFS-utils update since I filed this bug and this issue appears to be ok now. I just installed F12 (using net install) onto a laptop, set up a share using system-config-nfs and there wasn't an http: added to the IP. So on the other pc I opened the nfs config application and deleted the entry with the http and closed, and checked /etc/exports and it's just the one share I entered.

There was an update to nfs-utils that I downloaded on Nov 18th (from 1.2.0-18 to according to my yum log. Maybe that made the difference?

However, since bug 530591 was closed as a duplicate of this one, I thought I'd add that I still can't mount a share to the laptop, it times out. I just compared the output from rpcinfo -p on both machines, and on the laptop it appears there is no rquotad listed. It's assigned to port 910 on both machines, and I just confirmed it's configured under server settings for rpc.rquotad 

I don't know what the differences may be between the two, except that I used netinstall to install to the laptop (and it did a text only install to runlevel 3 so I had to add some groups and fix that to get a desktop.) They also have slightly different kernels, the pc is running the x64 kernel and the laptop has kernel 

Is there a new bug, or ?
Comment 4 Bug Zapper 2010-11-04 02:39:29 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 5 Cia Watson 2010-11-05 12:15:46 EDT
Closing as this appears to work as expected now on Fedora 13 (i686).

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