oneill@bu-tyng.bu.edu (Brian O'Neill) (10/23/88)
We've just set up to use NFS on our main system, and connect all our PC's to
it using PC-NFS. We seem to be having a slight problem with it. It will not
mount a drive to the server.
Currently, we are using PC-NFS 3.0 on a single PC for testing. It has a
3C503 Etherlink board. Our server system is an Encore Multimax 320, running
UMAX (BSD) 4.2, and a server-only NFS. nfsd and portmap run fine, and the PC
can communicate properly over the Ethernet using ftp and telnet, but the
problem comes when we try to mount a drive to a path on the server. I
compiled rpc.pcnfsd, commenting out the includes for sys/tty.h and
sys/stream.h, as they do not exist on the Encore, and did not produce a
compiler error.
rpc.pcnfsd runs fine, and both systems recognize it using
'rpcinfo -u bu-tyng 150001 1', responding with 'ready and waiting'. When I
run nfsconf or net use, and attempt to mount a drive, it comes back with:
NFS038F: Access to file system denied by server.
as if the path was not in the /etc/exports file, which it is. Here is a
closer look:
/etc/exports
# This file lists directories exported by NFS
/usr1/nfs/common
C\> net use d: \\bu-tyng\usr1\nfs\common
NFS038F: Access to file system denied by server.
NFS008F: Drive d: has not been mounted.
And I get the same error using nfsconf.
Any help would be appreciated, hopefully both sides (Sun and Encore) are
listening...
===========================================================================
Brian O'Neill - Boston University Corporate Education Center, Tyngsboro, MA
UUCP: {decvax!elrond,ulowell}!bu-tyng!oneill --------- oneill@bu-tyng.UUCP
Internet: oneill@bu-tyng.bu.edu (617) 649-9731 x14
--
===========================================================================
Brian O'Neill - Boston University Corporate Education Center, Tyngsboro, MA
UUCP: {decvax!elrond,ulowell}!bu-tyng!oneill --------- oneill@bu-tyng.UUCP
Internet: oneill@bu-tyng.bu.edu (617) 649-9731 x14clements@bbn.com (Bob Clements) (10/25/88)
In article <1747@bu-tyng.bu.edu> oneill@bu-tyng.UUCP (Brian O'Neill) writes: >We've just set up to use NFS on our main system, and connect all our PC's to >it using PC-NFS. We seem to be having a slight problem with it. It will not >mount a drive to the server. > >Currently, we are using PC-NFS 3.0 on a single PC for testing. > ... When I >run nfsconf or net use, and attempt to mount a drive, it comes back with: > >NFS038F: Access to file system denied by server. > >as if the path was not in the /etc/exports file, which it is. Here is a >closer look: I just had the same symptom after upgrading from v2 to v3.0 of PC-NFS on my machine, bobcat.bbn.com. After a fair amount of fooling around, it turns out that version 3.0 mucks around with the name of the PC before sending it out in the mount request to the server. In version 2, the request was sent from "bobcat.bbn.com". In version 3, the request is sent from "bobcat". No matter how you try to configure it. A workaround is to have "bobcat" instead of "bobcat.bbn.com" in the netgroup file on the servers. I'm not thrilled with that solution. This is the old "fully qualified or not" issue in Sun system administration. For reasons lost in history and which are not about to be changed, we have fully qualified $HOSTNAMEs and netgroup files and so on in our department. Version 2 allowed either way (as long as the total hostname was short enough). Version 3 doesn't. I don't know whether this is your problem, Brian, but check it out. I have an open problem report to Sun on this. No fix yet. >=========================================================================== >Brian O'Neill - Boston University Corporate Education Center, Tyngsboro, MA >UUCP: {decvax!elrond,ulowell}!bu-tyng!oneill --------- oneill@bu-tyng.UUCP >Internet: oneill@bu-tyng.bu.edu (617) 649-9731 x14 >=========================================================================== /Rcc Bob Clements, clements@bbn.com, 617-873-3612
dupuy@douglass.columbia.edu (Alexander Dupuy) (10/25/88)
One technique I have found useful in dealing with fully qualified vs. unqualified hostnames is to do the following in /etc/netgroup: a-real-group onemachine anothermachine thirdmachine onemachine (onemachine,,) (onemachine.dom.ain,,) anothermachine (anothermachine,,) (anothermachine.dom.ain,,) thirdmachine (thirdmachine,,) (thirdmachine.dom.ain,,) This way you can define your netgroups by machines, not umpteen aliases, but still accept both fully qualified and unqualified hostnames. We have a mix of Suns and Vaxen running 4.3+NFS, some of which use qualified, and some of which don't - this system deals with them all. This also helps with problems where the "canonical" hostname (first one in /etc/hosts, or returned by ypmatch) varies, depending on whether or not the domain nameserver is running (and whether it's returning capitalized entries or not). @alex -- inet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy
geoff@eagle_snax.UUCP ( R.H. coast near the top) (10/26/88)
In article <1747@bu-tyng.bu.edu> oneill@bu-tyng.UUCP (Brian O'Neill) writes: >[...] When I >run nfsconf or net use, and attempt to mount a drive, it comes back with: > >NFS038F: Access to file system denied by server. > >as if the path was not in the /etc/exports file, which it is. Here is a >closer look: > >/etc/exports "Access denied...." can actually mean two things: the path is not exported (to you), or the mount daemon doesn't think you have the necessary privileges to issue a mount request. For example, in SunOS 4.0 the mount daemon will reject any request coming from a non-privileged port (1024 or higher) unless it it started with the "-n" flag. From the man page for "mountd(8)": OPTIONS -n Do not check that the clients are root users. Though this option makes things slightly less secure, it does allow older versions (pre-3.0) of client NFS to work. (They mean client PC-NFS :-) Encore may well have modified this code to perform additional verification. Is the file system mountable from other machines? -- Geoff Arnold, Sun Microsystems Inc. +------------------------------------+ PC Distributed Systems(home of PC-NFS)|Someone, somewhere, wants an RFC822 | UUCP: {hplabs,decwrl...}!sun!garnold |message from YOU. | ARPA: garnold@sun.com +------------------------------------+
boneill@hawk.ulowell.edu (SoftXc Coordinator) (10/26/88)
[Oh Great Usenet, why doesn't this work????]
Thanks to all who responded promptly to my inquiry. As I picked up the phone
to call Encore, a gentleman from Encore called me (sorry, I can't remember
your name, but thanks a lot). Apparently, the preliminary copy of the NFS
manual wasn't very specific that the /etc/exports file must contain the root
of a file system, not just any directory. I haven't had the experience with
NFS before, so I wasn't aware of this.
==============================================================================
Brian O'Neill, MS-DOS Software Exchange Coordinator
ArpaNet: boneill@hawk.ulowell.edu
UUCP: {(backbones),harvard,mit-eddie,et. al.}!ulowell!hawk.ulowell.edu!boneillroy@phri.UUCP (Roy Smith) (01/14/89)
We've recently gotten PC-NFS runnng on a PC-AT and have noticed a
couple of problems. One is that when I run NFSRUN, when it gets up to the
"NET START RDR", it hangs for a few seconds and then I get:
Cannot send broadcast packet: unknown error
NFS028W: unable to find a YP server for domain PHRI
net: unable to get hostname by IP addr (128.122.136.101)
The odd thing is that it then procedes to run through the rest of
the NFSRUN script and when it's done (almost) everything appears to work
just fine. YP is obviously working since it's able to resolve hostnames
without any problem (and without a local hosts file). NFS, Telnet, and NET
PRINT all work too.
The second problem is that I can't seem to reliably talk to my Mt
Xinu 4.3BSD/NFS Vax using NFS. I can mount a file system from the vax and
access it doing simple things (i.e. I can cd to it, do ls and cat, and copy
small files from the PC to the vax) but if I try to write a large (i.e.
Mbyte) file it eventually hangs. I've never seen any problems with file
systems mounted from a Sun (SunOS-3.5.2) server. The only thing I can
think of is that the vax has a problem with dealing with large block sizes.
All our suns mount the vax file systems with (rsize=2048,wsize=2048). Is
it possible that I'm seeing the same problem with PC-NFS? Is there any way
to change the block size PC-NFS uses? Somehow, the idea of a PC sending
data too fast for a vax doesn't sound right, but that's all I can think of.
--
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"geoff@eagle_snax.UUCP ( R.H. coast near the top) (01/16/89)
In article <3650@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > We've recently gotten PC-NFS runnng on a PC-AT and have noticed a >couple of problems. One is that when I run NFSRUN, when it gets up to the >"NET START RDR", it hangs for a few seconds and then I get: > > Cannot send broadcast packet: unknown error > NFS028W: unable to find a YP server for domain PHRI > net: unable to get hostname by IP addr (128.122.136.101) > I assume you're using subnets and broadcasting for a YP server (NET YPSET *), Roy. There is a bug in PC-NFS 3.0 which screws up YP broadcasts in a subnetted network ("inet_netof" was inadvertantly left typed "int" instead of "unsigned long"). It's fixed in the next release: the workaround is to set the YP server explicitly. I'm not sure why everything works after the glitch.... > The second problem is that I can't seem to reliably talk to my Mt >Xinu 4.3BSD/NFS Vax using NFS. I can mount a file system from the vax and >access it doing simple things (i.e. I can cd to it, do ls and cat, and copy >small files from the PC to the vax) but if I try to write a large (i.e. >Mbyte) file it eventually hangs. I've never seen any problems with file >systems mounted from a Sun (SunOS-3.5.2) server. The only thing I can >think of is that the vax has a problem with dealing with large block sizes. >All our suns mount the vax file systems with (rsize=2048,wsize=2048). Is >it possible that I'm seeing the same problem with PC-NFS? Is there any way >to change the block size PC-NFS uses? Somehow, the idea of a PC sending >data too fast for a vax doesn't sound right, but that's all I can think of. This comes up occasionally. I thought that Mt.Xinu had fixed it long ago, but in any case there may be other implementations with this bug. The problem is that certain people ported the Sun NFS code a little too casually, without delving into the machine dependent issues. In the original nfs/nfs_subr.c file you'll find this little procedure: /* * Returns the prefered transfer size in bytes based on * what network interfaces are available. */ nfstsize() { register struct ifnet *ifp; for (ifp = ifnet; ifp; ifp = ifp->if_next) { if (ifp->if_name[0] == 'e' && ifp->if_name[1] == 'c') { return (ECTSIZE); } } return (IETSIZE); } In nfs/nfs.h, ECTSIZE and IETSIZE are defined: /* * maximum transfer size for different interfaces */ #define ECTSIZE 4096 #define IETSIZE 8192 Now of course all of this is strictly machine dependent, but anyone who didn't bother to check this will wind up with an NFS server that will advertise a TSIZE of 8192 unless the interface name begins "ec". Back at the first couple of Connectathons we ran into a number of implementations which were using third-party TCP/IP packages that couldn't handle 8K UDP datagrams, and of course the combination failed. Fortunately the fix was easy. There's no PC-NFS equivalent to WSIZE and TSIZE on mounts - any value you patched would be overwritten by the TSIZE obtained from the server. The best solution is to adb your Vax kernel and check out the nfstsize() code, patching it if necessary. -- Geoff Arnold, Sun Microsystems Inc. | "It is well known that the longer one PC Dist. Sys. Group (home of PC-NFS) |postpones a pleasure, the greater the UUCP: {hplabs,decwrl...}!sun!garnold |pleasure when it arrives. Therefore, if ARPA: garnold@sun.com |one postpones it forever..." (Smullyan)
geertj@nlgvax.UUCP (Geert Jan de Groot) (01/24/89)
In article <3650@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > We've recently gotten PC-NFS runnng on a PC-AT and have noticed a >couple of problems. One is that when I run NFSRUN, when it gets up to the >"NET START RDR", it hangs for a few seconds and then I get: > > Cannot send broadcast packet: unknown error > NFS028W: unable to find a YP server for domain PHRI > net: unable to get hostname by IP addr (128.122.136.101) > > The odd thing is that it then procedes to run through the rest of >the NFSRUN script and when it's done (almost) everything appears to work >just fine. YP is obviously working since it's able to resolve hostnames >without any problem (and without a local hosts file). NFS, Telnet, and NET >PRINT all work too. I have had the same trouble at our site. Even worse, it sometimes really couldn't find a YP server and didn't start up properly. A quick overview: we have a number of sun3 fileservers running SUNOS3.5, a sun4 fileserver running SUNOS3.2, an ULTRIX vax, and a sun386 roadrunner. Anyway, an experiment with etherfind shows what happens: the pc sends a RARP broadcast, and then one of the servers (probably more) respond. Then the PC sends some UDP packets to the same machine it got the first RARP response from. It apperently clamps itself to that machine asking for more info. Now, if the responding machine was one of the sun3 machines, all works well. However, if one of the other architectures is faster, I got the same messages you did. Apperently, something botches with the other architectures. Depending on the load of these machines, you get an unstable situation: if the sun3 fileservers are busy, no PC is able to hook into the network, because the other machines are less loaded, are faster and win the race. As temporary fix, we switched off all rarp daemons, except for the sun3 machines. This way, a sun3 fileserver always wins. Since then, everything runs smoothly. This of course is only a temporary fix. (I *hope* PCNFS will work with SUNOS 4.0 on the sun3 machines !). Setting the YP server explicitly does not help, because YP will need the ARP data, and loses there. I have reported the problem to SUN but have had no answer yet. BTW: does anybody have had any luck with the DOS APPEND command and PCNFS? APPEND doesn't work if either the current drive or the append drive is an NFS drive. If they are both local (winchester of floppy), APPEND works. Anybody any ideas? Geert Jan -.-.- --... ...-- -.. . .--. . .---- .... --.. --. .-.-. Geert Jan de Groot, Email: geertj@nlgvax.pcg.philips.nl Philips Research Laboratories, Packet: PE1HZG @ PI8ZAA Project Centre Geldrop, AMPRNET: [44.137.24.3] Building XR, Room 15, Willem Alexanderlaan 7B, "When in doubt, 5664 AN Geldrop, The Netherlands. tune for minimum smoke phone: +31 40 892204 and then consult a reference" [Standard disclaimers apply] -(Found in a manual)