From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; WMM)
Description of problem:
The NFS Server Configuration tool does not work propperly. When you save NFS
share with this tool, then in the configurationfile is in some cases a
seperator missing. The share will not work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.In X-Windows the Redhat
5.Put in directoryname to share
6.put in ip-adress of home network: 192.168.1.*
8.Try to mount the share on an other computer
Share does not work --Error not authorized
Expected Results: Mount of directory
If i use only the name of the computer it works.
Do i use just the ipadress with as last character a *, it does not work.
DO I USE the IP-ADRESS with a SPACE as last character it does work
(ea. 192.168.1.*_)(last char= space)
The error is in writting the configuration away in the config-file /etc/exports.
looks something like this:
/home/arnold 192.168.1.* (ro,sync)
The first one works, the second one NOT, the tird one works also.
It works fine on my test machines. Here's my /etc/exports:
[bfox@bfox redhat-config-nfs]$ cat /etc/exports
I can't reproduce this problem at all.
I created a new export file. It looks like this:
/home/8 192.168.1.* (ro,sync) (space between * and (
option 1,2 and 4 work and 3 does not.
I get the following message, when i try to mount it, (on the other computer)
command: mount sun:/home/7 /import
reply: mount: sun:/home/7 failed, reason given by server: Permission denied
I don't understand why i get no permission to mount the file system. When i
give the ip-number or the name it works. Why not with a *?
I have a network of only 2 pc's at this moment.
Can this problem have something to do with just one wildcard in the
option 4 works when i try to mount it.
with option 4 i get the following warning by a /sbin/service nfs reload
exportfs: No options for /home/8 192.168.1.*: suggest *(ro,sync) to avoid
exportfs: No 'sync'or 'async'option option specified for
Assuming default behaviour ('sync')
NOTE: this default has changed from previous versions
exportfs: No hostname given with /home/8 (ro,sync), suggest *(ro,sync) to avoid
When i do a /sbin/services nfs start or restart i get no warnings !!!!!
the exports table can not be read in by the Xwindow nfs server. The program
will not start. When i remove the space(s)from the file the Window nfs server
can be loaded again. (It will save the space the first time)
I think I've fixed this with redhat-config-nfs-1.0.4-3 in Rawhide. QA, please
The tool default installed with redhat 8.0 is NFS Server Configuration Tool
I did a rpm -q redhat-config-nfs and get as result redhat-config-nfs-1.0.1-3
Can you tell me where i can find Redhat-config-nfs-1.0.4-3 on the redhat server
Upgrade to the latest redhat-config-nfs package and that should fix the problem.
I installed Redhat-config-nfs-1.0.4-3. The first thing i discovered there is no
apply button, but the configuration is saved as i quit the program.
I placed the new nfs on Moon (22.214.171.124)
The exports file on moon looks like this
/home/8 192.168.1.* (ro,sync) (space between * and (
On sun i tryed to mount with:
mount sun:/home/5 /import okee
mount sun:/home/6 /import okee
mount sun:/home/7 /import error (Permission denied)
mount sun:/home/8 /import okee
Still the same error exists.
The file is saved with spaces into the exportfile
When you modified the exportfile with redhat-config-nfs again, the lines with
space after the * and before the ( ; the spaces are removed. The line which is
edited is writen away with a space when you try this.
127.0.0.1 localhost.localdomain localhost
192.168.1.1 sun.galaxy sun
192.168.1.2 moon.galaxy moon
prim DNS: 194.134.xxx.yyy
sec DNS: 194.134.xxx.zzz
tet DNS: kkk.lll.mmm.nnn
localdomain <-- i think this is not neccessary
galaxy <-- i think this is not neccessary
i think there is no error in this configuration why there is
an error with *( and not with * ( in the export file
I don't now if i'm doing something wrong and and if what ????
redhat-config-nfs will only modify /etc/exports if you actually make a change to
one of the entries in the application.
So, if the /etc/exports file has some spaces in it and you run redhat-config-nfs
but don't change anything, then the file will not be modified.
If you change anything in the program (add, edit or delete a share), then
redhat-config-nfs should write a new /etc/exports file that should remove the
unneeded spaces that were in the file before.
My guess at this point is that the versions of NFS on Sun and Linux may be
having some compatibility problems. I don't have a Sun machine to test this
with. Can you try mounting one of those exports on a Linux machine?
Sorry, If i was not clear. The machine is not a Sun machine, but is called Sun.
The machines are both i686.
Sun = i686 (P3) 500MHz, 128 Mb, running RH8.0 and Win98 (dualboot)
Moon= i686 (P4) 2,53GHz, 512Mb, running RH8.0 and WinXp (dualboot)
If things normally work, when you put the data in with the redhat-config-nfs
server program. Where or what is used too make clear if authorization is
permitted. Is there any table or variable which i have to fill in first and
maybe in some particulair way. The strange thing is, i think i'm doing the
right thing but something doesnot work like i suspect.
This is a very difficult problem. When the adress off the allowed client is
given exactly as an ip adress or an allias, it works.
But only not with a "*". There should be some translation process (i think) and
during this, the match is not made 192.168.1.1 is one of the adresses of
The program redhat-config-nfs-1.0.4-3 worked exactly as you discribed and also
loads files with spaces, what the original program does not !!!
Oh, ok. I thought that you had a Sun box.
So are things fixed with 1.0.4-3? If so, I'll close this bug report.
The problem with the loading of the file in redhat-config-nfs is fixed.
But the problem of getting access from a computer in the correct ip-range, to a
nfs-host with in the exportsfile the range with a * is not solved.
host with exportsfile
/home/6 192.168.1.* (ro,sync)
can mount home/6 but not home/5
Oh, I see what you're saying. According to 'man exports', wildcards aren't
valid for IP configuration, so you shouldn't try to do it like that.
Unfortunately, the documentation recommends doing it like that, so I'm reopening
the bug so that the docs are changed.
Perhaps I could pop up a dialog to telling the user not to use wildcards in the
IP address, but we're past string freeze for the next release of Red Hat Linux,
so I make this change now.
tfox, let me know when you've updated the docs and I'll build a new version.
Docs are fixed in CVS. Please rebuild.
Ok, should be fixed in redhat-config-nfs-1.0.4-4. QA, please verify.
If you already have wildcards in your /etc/exports file, then I think it's
beyond the scope of redhat-config-nfs to handle that. The error handling
capabilities of redhat-config-nfs is somewhat limited by the ambiguities of what
is and isn't valid input to /etc/exports.
For example, if a user tries to enter 123* in the "Hosts" field, I have no way
of knowing if that represents an IP address (which would be invalid) or if it
represents a group of hostnames (like 123-lab.redhat.com, which would be valid).
Okee, i can understand that.
I did use a possibility what was documentend but not implemented, so it dopes
I do have one question left:
In comment 2 Bfox claims that it works with a * in the ip-adress for /opt. My
question is now; does it our does it not work ???
Or was this line never tested ???
I tested it on my network at home, which does not have a DNS server set up. As
'man exports' says:
"Wildcard characters generally do not work on IP addresses, though they may
work by accident when reverse DNS lookups fail."
Which was what was happening to me. Once I tested it at work, the DNS lookups
succeeded, which caused the wildcard characters in the IP address to not work.
I tryed the new version. And so far i could test it worked fine.
I did test with a correct exportfile.
There is No Apply button in the top, like by version 1.0.1-3.
I did also test the oter posibility's
this worked fine
There is a stack of 64 bugs that have been in Modified state for a long period
of time. I am closing these as Rawhide now. If you find that the issue is not
fixed, please reopen this report.