y-yokoym@sran129.sra.co.jp (Yoshiyuki yokoyama) (09/27/90)
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.
aks@somewhere.ucsb.edu (Alan Stebbens) (09/28/90)
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 <aks@hub.ucsb.edu>
madd@world.std.com (jim frost) (09/28/90)
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. We didn't have any problems except that exporting to the Sun required using the fully-qualified hostname or else the IBM would deny access (ie if your host is `foo' and your domain is `bar.edu' you MUST give the hostname `foo.bar.edu' exports permission -- `foo' alone will not work). A number of other networking tools such as rlogin show the same behavior. Note that if root has its shell as /bin/ksh and a user whose home directory is NFS mounted from the Sun tries to `su', ksh will hang and create a hell of a lot of NFS traffic until the ksh is killed. Changing root's shell to /bin/csh corrected the problem for us. jim frost saber software jimf@saber.com
aks@somewhere.ucsb.edu (Alan Stebbens) (10/02/90)
In <1990Sep28.153207.12874@world.std.com> madd@world.std.com (jim frost) writes: >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. >We didn't have any problems except that exporting to the Sun required >using the fully-qualified hostname or else the IBM would deny access >(ie if your host is `foo' and your domain is `bar.edu' you MUST give >the hostname `foo.bar.edu' exports permission -- `foo' alone will not >work). A number of other networking tools such as rlogin show the >same behavior. This can be avoided by creating a local /etc/hosts file on the YP master server which contains the "plain" names of your hosts, in addition to the FQDN (FQDN = Fully Qualified Domain Name). "ypserv" always consults its maps first, after which it will do a domain query (if the host maps were built with "makedbm -b"); thus, by placing the plain names in the maps, they should always be resolvable. After propogating the new host file, all system name references via "telnet", "rlogin", and "rsh", and mentions in configuration files like "/etc/fstab" and "/etc/exports", do not have to be fully domain qualified. One other problem: if "root" is in more than eight groups, many of the configuration scripts run by SMIT will fail, especially the ones for NFS. -- Alan Stebbens <aks@hub.ucsb.edu>
madd@world.std.com (jim frost) (10/02/90)
aks@somewhere.ucsb.edu (Alan Stebbens) writes: >In <1990Sep28.153207.12874@world.std.com> madd@world.std.com (jim frost) writes: >>[...] exporting to the Sun required >>using the fully-qualified hostname [...] >This can be avoided by creating a local /etc/hosts file on the YP master >server which contains the "plain" names of your hosts, in addition to >the FQDN (FQDN = Fully Qualified Domain Name). We already have this, and it works for every other host on our net except the RS/6000. The really bothersome thing is that it's only the authentication software that requires the full hostname -- rsh, telnet, and the like all work as expected but exports and incoming rsh's do not. Note that our YP server is a Sun, not an IBM. Happy hacking, jim frost saber software jimf@saber.com
ehrlich@cs.psu.edu (Dan Ehrlich334B W) (10/05/90)
In article <606@sran251.sra.co.JP> y-yokoym@sran129.sra.co.jp (Yoshiyuki yokoyama) writes:
Yoshiyuki> We can't set up NFS between Sun SPARC Station and RS/6000.
Yoshiyuki> Please teach us if you know how to do it.
We could not run NFS between Suns and our RS/6000 until we upgraded AIX to
the 9030G release. Ask your IBM SE to get 9030G for you and life will be
a little bit easier.
--
Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176lixj@acf4.nyu.edu (Xiaojian Li) (05/23/91)
I constantly receive the following message while the NFS works properly: Cannot register service: RPC: Timed out Unable to register (NLM_PROG, NLM_VERS, tcp). Cannot register service: RPC: Timed out rpc.statd: unable to register (NLM_PROG, NLM_VERS, udp). I would be happy to hear from anybody about how to get rid of these annoying things. Thanks in advance. XJ
lixj@acf4.nyu.edu (Xiaojian Li) (05/23/91)
lixj@acf4.nyu.edu (Xiaojian Li) writes: >I constantly receive the following message while the NFS works properly: > Cannot register service: RPC: Timed out > Unable to register (NLM_PROG, NLM_VERS, tcp). > Cannot register service: RPC: Timed out > rpc.statd: unable to register (NLM_PROG, NLM_VERS, udp). >I would be happy to hear from anybody about how to get rid of these annoying >things. >Thanks in advance. >XJ I forgot to say I am am using a RS6000/320 running AIX3.1
marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (05/24/91)
In article <1991May22.171846.11932@cmcl2.nyu.edu> lixj@acf4.nyu.edu (Xiaojian Li) writes: >I constantly receive the following message while the NFS works properly: > Cannot register service: RPC: Timed out > Unable to register (NLM_PROG, NLM_VERS, tcp). ... I believe that this occurs when you do not have the portmapper running, as in /usr/etc/portmap. Check to see if you have the line starting portmap commented out in /etc/rc.tcpip. You can start it up from the command line as well. -- Marc Stephenson IBM PSPA (Personal System Programming - Austin,TX) DISCLAIMER: The content of this posting is independent of official IBM position. marc@stingray.austin.ibm.com VNET: MARC at AUSVMQ IBM T/L: 793-3796