Description of problem:
exportfs, when re-exporting filesystems, instead unexports them.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1) On server added the folowing to file /etc/exports :
2) On server restart nfs :
# service nfs restart
3) On client mount/unmount (WORKS) :
# mount server123.redhat.com:/tmp /mnt/tmp
# umount /tmp/mnt
4) On server re-export /tmp :
# exportfs -rv
unexporting client123.redhat.com:/tmp from kerne
/tmp is not exported in the kernel, and subsequent attempts to mount the file
system from a client result in getfh: permission denied messages on the client
and from rpc.mountd on the server
filesystem should continue to be mount-able.
I'm attaching my patch to correct this. It appears when re-exporting, the
rebuild of the export database in xtab_read, when reading /proc/fs/nfs/exports,
fails to set the m_mayexport flag, as it does when reading /var/lib/nfs/xtab.
The result is that exportfs interprets this as a indicator to explicitly
unexport the mount. The attached patch corrects this, and has been successfully
tested by the customer
Created attachment 117133 [details]
patch to set maymount flag for database built from /proc/fs/nfs/exports
From User-Agent: XML-RPC
The patch provided by SEG (nhorman) has been tested in the GSS lab to
resolve the problem and allow the mounts to work correctly past the point
the 'exportfs -rv' is run on the server.
Requesting Dell L3 or customer to test the patch
(nfs-utils-1.0.6-reexport.patch) attached in this case and confirm the
This event sent from IssueTracker by sbenjamin
The above patch was added to nfs-utils-1.0.6-40EL.
*** Bug 126129 has been marked as a duplicate of this bug. ***
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.