Mar 24 11:31:06 maya mountd[26991]: refused mount request from aztec.incanta.net for /homes7 (/): no export entry BUT(!) [miker@aztec miker]$ cat /etc/netgroup kennedy (aztec.incanta.net,,) (maya.incanta.net,,) (llama.incanta.net,,) (euterpe.incanta.net,,) (llama.incanta.net,,) (euterpe.incanta.net,,) (lumux.incanta.net,,) (oasis.incanta.net,,) (which is nis exported from aztec) and [miker@maya miker]$ cat /etc/exports /homes2 *.field.incanta.net(ro) @kennedy(rw) nile.purplefrog.com(rw) /homes4 *.field.incanta.net(ro) @kennedy(rw) nile.purplefrog.com(ro) /homes5 *.field.incanta.net(ro) @kennedy(rw) nile.purplefrog.com(ro) /homes6 *.field.incanta.net(ro) @kennedy(rw) nile.purplefrog.com(ro) /homes7 *.field.incanta.net(ro) @kennedy(rw) nile.purplefrog.com(ro)
assigned to johnsonm
I still see this with both client and server running 7.2 (+all updates).
*** Bug 5202 has been marked as a duplicate of this bug. ***
There were no activity on this bug for over a year and I still see it in 7.2. Should it be reassigned "to owner of selected component (bmatthews)"? P.S. I also want to mention that what I see in 7.2 is very similar to what originally reported in that it complains "... for /xyz (/): no export entry" e.g. it is looking for an export entry for *root fs* even though /xyz is a separate fs and has a separate entry in /etc/exports (and if I explicitly list the client instead of just using a netgroup entry, then the log message would say that access to "/xyz (/xyz)" was granted).
How the hell do people manage /etc/exports on an honest-to-god network of machines? Maybe everyone who exports a partition to more than 3 machines runs Solaris instead of Linux. It is drastically pathetic that his hasn't been fixed yet.
The netgroups issue should have been fixed back in nfs-utils-0.3.1-1. What version of nfs-utils is running on the server? Might also be a NIS problem. What happens if you copy /etc/netgroup to the server and restart nfs services?
nfs-utils-0.3.1-13.7.2.1 I do not have admin access to the server (and it's running on Solaris), but ypcat -k netgroup seems to do the right thing. Here are the relevant parts of my setup: server% ypmatch somegroup netgroup ... client ... server% ypmatch client netgroup (client,-,) (client.cs.cornell.edu,-,) (CLIENT,-,) (CLIENT.CS.CORNELL.EDU,-,) /etc/exports on server: /some_partition @somegroup(rw) ... log gets: <date> server rpc.mountd: refused mount request from client.cs.cornell.edu for /some_partition (/): no export entry
> I still see this with both client and server running 7.2 ... > I do not have admin access to the server (and it's running on Solaris) These two statements contradict one another. Nevertheless, this appears to be entirely a server side issue. The nfs-utils are not even required to be installed on the client side in order to import directories. You aren't trying to re-export an nfs-mounted directory, are you? If so, that is specifically disallowed by the NFS v2 and 3 protocols.
The *NFS* server is running RH7.2 and is controlled by me. The *YP* server is on another machine running Solaris and not controleld by me. > You aren't trying to re-export an nfs-mounted directory, are you? No, it's a local fs. And it works fine as long as I list the client explicitly in /etc/exports. I tried this on another pair of 7.2 machines (in the same NIS domain&group), same result.
Ah, this was so dumb of me! I didn't realize that /etc/nsswitch.conf only had nisplus and not nis for netgroup. After I've updated it, everything started working properly!
*** Bug 8839 has been marked as a duplicate of this bug. ***
We opened this ticket, and I'm pleased to say that on our boxes that run 7.1, the problem is solved. The NFS server supports netgroup-based exports. Our 6.2 boxes still do not. They have nfs-utils-0.1.7-1 . Has redhat released an erratta for 6.2 that fixes this problem, or is the solution "upgrade the whole OS" ?
We actually didn't release an errata specifically for 6.2, but the netgroups fix has been in since nfs-utils-0.3.1-1. I believe this should work for 6.2 boxes, but it hasn't been tested against such.