Path: utzoo!attcan!uunet!nih-csl!lhc!adm!cmcl2!yale!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!hub.ucsb.edu!somewhere.ucsb.edu!aks From: aks@somewhere.ucsb.edu (Alan Stebbens) Newsgroups: comp.unix.aix Subject: Re: NFS(between Sun SPARC Station and RS/6000) Message-ID: <6370@hub.ucsb.edu> Date: 28 Sep 90 01:26:21 GMT References: <606@sran251.sra.co.JP> Sender: news@hub.ucsb.edu Organization: CCSE, Univ. of CA, Santa Barbara Lines: 66 In <606@sran251.sra.co.JP> y-yokoym@sran129.sra.co.jp (Yoshiyuki yokoyama) writes: >We can't set up NFS between Sun SPARC Station and RS/6000. >Please teach us if you know how to do it. > Yoshiyuki Yokoyama -- y-yokoym@sra.co.jp > SOFTWARE RESEARCH ASSOCIATES, INC. I had a RS/6000 model 320, running release 9013. It had serious problems with the networking code. After obtaining a pre-release of 9021, the problems went away, and I was able to mount to and from both a SPARCstation and a DECstation 3100, both with internal and external SCSI disks. As the unit was a demo, only after becoming familiar and happy with the system, did I actually order a couple. Many things can affect the proper operation of the networking code: Which version of the OS do you have? Do you have release 9021 or later? Is the RS6000 hostname set correctly? Is it registered within its subdomain? Do you use broadcast zeroes or ones? Is it set correctly? Are you using subnetting? Is the netmask set correctly? Are you using a nameserver? Is the resolver code working correctly? NFS mounts rely on proper name resolution. If you are not using a nameserver, then is your hosts table set correctly? Does the NFS server on the SPARC station know about the RS6000's new system name? Is the new system name known to your nameserver? Are there export limitations on the filesystem on the SPARC? After editing /etc/exports and adding the new RS6000 system name, did you run "exportfs -a"? One bug still existed even in the new release: don't use the "BACKGROUND" option when configuring NFS with the SMIT. It causes the system to go into an infinite fork-process loop when it reboots. My system worked and rebooted just fine using the "FOREGROUND" option only. If these suggestions don't get you anywhere, please send me email with some detailed symptoms of the failures and I'll try to help. (Hazimete, dozo yoroshiku. Ima nihongo o benkyoo shite imasu. Sukoshi nihongo de hanashimasu ga, mada takusan nihongo o benkyoo shina kereba narimasen. Tottemo omoshiroi desu.) Alan Stebbens Computer Resource Manager Center for Computational Sciences and Engineering (CCSE) University of California, Santa Barbara 3111 Engineering I Santa Barbara, CA 93106 Internet: aks@hub.ucsb.edu BITNET: aks%hub@ucsbuxa.bitnet UUCP: ...{ucbvax,sdcsvax,cepu}!ucsbcsl!aks Voice: (805) 893-8135 (CCSE Office: 893-3221) -- Alan Stebbens