From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
After working fine for about two weeks, the nfs server started failing
to export home directories to certain clients while others worked
fine. For the clients that were failing, the server would log errors
Jun 16 09:59:10 blackstar rpc.mountd: authenticated mount request from
zeke.sr.unh.edu:613 for /home/rcc/teh (/home/rcc)
Jun 16 09:59:10 blackstar rpc.mountd: getfh failed: Operation not
The only solution was to restart nfs and the problem went away.
Version-Release number of selected component (if applicable):
This is the first time this has ever happened. The server has been up
for two weeks and is fully updated.
This happened again today. Restarting NFS fixed it. If you have any
ideas on what to look for when it happens again, let me know.
FWIW, it happens occasinally here too.
If you have a support contract, you might be best off going through
support the next time this happens:
We're getting the same messages here with RHAS 3.0
This seems to be unresolved for quite some time:
We're working around the problem by adding a CRON job that re-exports
every four hours:
We also have this problem. Exportfs -r does not fix it, only
This is a showstopper for us. We have can kludge to fix this but we
would rather have it work.
Here is our synopsis:
We have a few boxes setup to evaluate NFS server replacement. Two of
them are running Redhat Enterprise 3 AS. One of them is a little behind
in terms of updates and is running an XFS (SGI journaled filesystem)
enabled kernel. The other is fully up to date in Redhat's view.
Everything works EXCEPT....
Filesystems are exported to netgroups. Netgroups come from NIS.
Client mounts filesystem and then unmounts. This is typical behavior for
us since we use automounted filesystems.
While unmounted, exportfs is run on the server.
Client can no longer mount the file system.
Only way to restart service for that client is to do
If the client is explicitly listed in /etc/exports, not @netgroup, it
does not fail.
Log message on the server is:
Feb 2 08:24:28 SERVER rpc.mountd: authenticated mount request from
CLIENT.me.umn.edu:931 for /scratch/test (/scratch/test)
Feb 2 08:24:28 SERVER rpc.mountd: getfh failed: Operation not permitted
If exportfs is run while the client has it mounted, there is no problem.
Exportfs behavior if filesystem is still mounted
[root@SERVER etc]# exportfs -va
reexporting CLIENT.me.umn.edu:/scratch/test to kernel
exportfs behavior if filesystem has been mounted and umnmounted.
[root@SERVER etc]# exportfs -va
unexporting CLIENT.me.umn.edu:/scratch/test from kernel
Eliminating NIS netgroups and using local files does not fix the
problem. The only fix seems to be an explicit export to each client.
This problem looks like it has been around for a long time, in some
form, even back in to RH 7.x. The "fixes" people report, that we have
found, offer us no remedy.
It looks like something is broken in rpc.mountd.
This problem is 100% repeatable. It is definitely a server issue. It
affects every client OS we run, Linux, IRIX, Solaris and FreeBSD.
I am experiencing the same problem, and it becomes really anoying .
If someone has a solution ... please let us know .
If this is a real bug (not tunning or configuration), should we
complain to redhat or we have to wait for a new kernel release ?
2.4.21-27.ELsmp on Red Hat Enterprise Linux ES release 3 (Taroon Update 4)
We have definitley narrowed pur problem down to netgroup expansion in
To remedy the situation, we have implemented a Perl script that reads a copy of
the original exports file, expands all netgroups to IP numbers for individual
hosts, and generates a new exports file with each host explicitly listed for
each exported directory. This has taken care of our problem.
It looks like this problem is gone in Fedora Core 3. Perhaps there is hope for
RHEL 4. We have a box getting setup with the Beta version to test.
Any news on whether or not this is fixed with RHEL4? I'm experiencing the same behaviour as above on
We did not see the problem on RHEL4.
Does exporting with 'no_subtree_check' help?
(In reply to comment #12)
> Does exporting with 'no_subtree_check' help?
Just out of curiosity, what uid is rpc.mountd running as? This is the error that
you would receive in the event that mountd was running as a non-root user.
Also, can you confirm that there are no other programs running which may be
registering a mountd rpc program that are running as non-root?
rpc.mountd running as uid 0
this is the output of rpcinfo (only the relevant):
100005 1 udp 981 mountd
100005 1 tcp 984 mountd
100005 2 udp 981 mountd
100005 2 tcp 984 mountd
100005 3 udp 981 mountd
100005 3 tcp 984 mountd
hmm... I wonder if this is the same problem as in
It does sound awfully close.
OK, I'm going to close this bug as a duplicate of bz164186.
Please reopen if this is not the case.
*** This bug has been marked as a duplicate of 164186 ***