The original question was:
>
> Dear sun-managers,
>
> I have a couple of machines within a subnet (137.132.169.xxx) and
> I have been using the -access=clientmachines in the /etc/exports to
> control mounting access (clientmachines is one entry in /etc/netgroup).
> Yesterday, when I was configuring a new IPX on another subnet and trying
> to mount one filesystem from a machine on the .169 subnet, I was refused
> access. This is after I have added the new IPX to the "clientmachines"
> netgroup and re-exportfs the filesystems. I couldn't think of another
> reason except that the new IPX is not running YP. Is it really neccessary
> to do so? Right now, I have to use -rw=host1:host2:... in /etc/exports to
> control write access but everybody can mount my filesystems ro.
> Any suggestion to circumvent this limitation? I'll summarise to the list.
> Thank you.
My apology to all that I forgot to mention that I have done a (cd /var/yp;make)
after I have changed the /etc/netgroup file and also that I'm running DNS
together with YP on my site and that new IPX has been registered with my
primary name server.
Many thanks to all of you who replied especially Ace Stewart <jstewart@mailbox.syr.edu>
who provided the correct hint. In his reply he wrote:
> Couple of things come to mind:
>
> 1) Make sure that the hostname is registerted with the NFS server,
> otherwise you are exporting to a machine it doesn't know about.
>
> 2) If you are running DNS, make sure that the entry in the
> clientmachines netgroup is lower/upper case compatible with the
> machine name itself.
>
> 3) Make sure the machine name you configured is correct, and it has
> the correct IP address.
>
> 4) ypcat the netgroups and make sure that the server has the current
> version of it, which includes you new host.
>
> 5) Try exporting a filesystem to the world and see if that is
> mountable on this new machine -- if it isn't, check for "smart
> routers" which are filtering packets.
>
The actual cause of the problem was with the name server. The new IPX
is known as "shenton". However, I have capitalise the "s" in the reverse
map on the name server. Everything works fine after I have changed that.
Here are the rest of the reply:
>From Mark Plotnick <mp@allegra.att.com>:
> did the client try to mount the filesystem before you had added
> its name to the netgroup? If so, the server's rpc.mountd may have
> added the client to its cache of clients that it believes don't have access.
> This cache is usually cleared pretty quickly, but perhaps
> you may have to kill and restart the rpc.mountd on the server.
>From Eckhard R"uggeberg <eckhard@ts.go.dlr.de>:
> You could write -access=host1:host2:...:hostn
>
> Dif you do a "make" in /var/yp after entering the new machine in the
> /etc/netgroup file on the YP server ? And did you do an
> "exportfs -ua;exportfs -a" on the file server AFTERWARDS ?
> That should work regardless of subnets and clients being in the domain
> of the file server ...
>From Robert Montjoy <montjoy@thor.ece.uc.EDU>:
> Netgroups are only consulted when running NIS(Yellow Pages). This
> is why you have to specify each host in the access control list.
>
> From Mike Raffety <miker@sbcoc.com>:
>
> Well, if you're running secure NFS, all the machines must be in YP, and
> in the same YP domain.
>
> Do both machines (client and server) have each other in their hosts
> files? For example, can they ping each other by the same name as the
> mounts being attempted?
>From Kevin W. Thomas <kwthomas@nsslsun.nssl.uoknor.edu>:
> After you added your new machine to /etc/netgroup, did you re-make the NIS/yp
> maps? After doing the make, do the "exportfs -a" again.
>
> Believe me, it is very easy to forget to remake the "netgroup" map.
>
> From Marvin Tay Eng Sin <marv@iti.gov.sg>:
>
> When u say another subnet do u mean something like e.g. 137.132.168.xxx ?
> If you are using class C addresses, I think you have to define a router
> to route packets between the 2 subnets. You might want to check your `netstat -r`
> to see where your other packets not on the 169 subnet routes to.
>
> I normally run NIS over the machines which mount each other. Makes life a
> whole lot easier. But if again, you are using Class C addresses, which I think
> you are, then you'd have to have a slave YP (not a client) on each subnet.
> NIS does not span across routers.
From Timothy Baum 432-2765 <satmb@gauss.med.harvard.EDU>:
> You don't mention whether you did 'cd /var/yp; make' on the
> master NIS server. If not, then the NIS netgroup map has not
> been updated, so even though the new IPX appears in /etc/netgroup
> the NIS netgroup takes precedence and access is denied.
>
> My other idea would have been to check that the hostname in
> /etc/netgroup matches exactly the official hostname for the IPX
> (as displayed by e.g. 'who am i' during an rlogin session from the
> IPX to the fileserver); however if your -rw=host1:host2...
> is working correctly then that would not be the problem.
>
> It should not be necessary for the client machine to be running
> NIS in order to mount the filesystem. You may, however, run into
> different problems like file permissions and improper access if the
> numeric userid's on the IPX do not match those on the server; but
> that's another story.
>
> Hope this helps...
>
>
================= END OF SUMMARY ==========================================
Won-Soon Lau
-- VLSI DESIGN & CAD LABORATORY \ INET: "lws%ee.nus.sg"@nuscc.nus.sg Dept of Electrical Engineering \ BITNET: ENGP2065@NUSVM.bitnet National University of Singapore \ Phone: (+65) 772 6319 10, Kent Ridge Crescent. Singapore 0511. \______________________________
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:50 CDT