tonytran@portia.Stanford.EDU (Tony) (04/09/91)
Hi there,
I recently upgraded my Next workstation from 1.0b to Next_2.0a.
I mounted a remote Apollo file system successfully, but I am only
able to access the Apollo if I were the root on the Next.
Does anyone know what I need to do in order to access the Apollo
while I am logged in as a regular user other than root on the Next?
(The Next tech support people said it should work :-)
Also, I trying mounting to the Next from the Apollo but is denied
access. It was working OK when the Next workstation was running
version 1.0b.
The Apollo system is running Domain Aegis 10.2.
Am I missing something real obvious?
Thanks in advance.
Tony
--------------------------{Session file}--------------------
Script started on Wed Dec 4 17:58:35 1991
next# ps aux
USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
root 315 9.1 7.0 1.65M 576K p2 R 0:00 ps aux
nobody 217 5.8 16.5 3.70M 1.32M ? S 2:46 - console (WindowServer)
root 292 3.5 8.9 3.42M 728K ? S 0:06 /NextApps/Terminal -MachLau
root 313 1.5 4.6 1.34M 376K p2 S 0:00 -h -i (csh)
root 311 0.3 2.6 1.31M 216K p1 S 0:00 script next
root 2 0.0 1.9 1.27M 152K co S 0:02 /etc/mach_init -xx
root 3 0.0 1.5 2.39M 120K ? SW 0:02 /usr/etc/kern_loader -n
root 50 0.0 1.8 1.24M 144K ? S 0:00 /usr/etc/syslogd
root 55 0.0 2.7 6.37M 224K ? S N 0:00 /usr/etc/nmserver
root 59 0.0 1.5 1.23M 120K ? SW 0:00 /usr/etc/portmap
root -1 0.0 0.0 0K 0K ? S 0:00 <mach-task>
root 63 0.0 3.3 1.29M 272K ? S 0:08 /usr/etc/netinfod local
root 66 0.0 3.0 1.33M 248K ? S 0:08 /usr/etc/lookupd
root 70 0.0 0.8 1.31M 64K ? S 0:00 /usr/etc/biod 4
root 71 0.0 0.8 1.31M 64K ? S 0:00 /usr/etc/biod 4
root 72 0.0 0.8 1.31M 64K ? S 0:00 /usr/etc/biod 4
root -1 0.0 0.0 0K 0K ? SW< 0:00 <mach-task>
root 84 0.0 1.3 1.24M 104K ? SW 0:00 /usr/etc/inetd
root 1 0.0 1.2 1.31M 96K ? SW 0:00 /usr/etc/init -xx
root -1 0.0 0.0 0K 0K ? ?W< 0:00 <mach-task>
root 62 0.0 1.9 1.25M 152K ? SW 0:00 /usr/etc/nibindd
root 73 0.0 0.8 1.31M 64K ? S 0:00 /usr/etc/biod 4
root 105 0.0 6.8 3.23M 560K ? S 0:01 /usr/lib/NextPrinter/npd
root -1 0.0 0.0 0K 0K ? S 0:00 <mach-task>
root 114 0.0 1.2 1.23M 96K ? SW 0:00 /usr/etc/nfsd 4
root 116 0.0 0.8 1.23M 64K ? SW 0:00 /usr/etc/nfsd 4
root 117 0.0 0.8 1.23M 64K ? SW 0:00 /usr/etc/nfsd 4
root 118 0.0 0.8 1.23M 64K ? SW 0:00 /usr/etc/nfsd 4
root 120 0.0 1.2 1.24M 96K ? SW 0:00 /usr/etc/rpc.mountd
root 130 0.0 1.3 1.31M 104K ? S 0:00 update
root 133 0.0 2.1 1.31M 168K ? S 0:00 cron
image 142 0.0 1.1 1.33M 88K ? SWN 0:00 Workspace Helper
root 90 0.0 1.3 1.34M 104K ? SW 0:00 /usr/lib/sendmail -bd -q1h
root 218 0.0 2.8 2.79M 232K ? SW 0:08 - console (loginwindow)
root 289 0.0 2.9 4.15M 240K ? SW 0:06 /usr/lib/NextStep/Workspace
root 290 0.0 1.1 1.25M 88K p0 SW 0:00 Console Daemon
root 95 0.0 1.6 1.29M 128K ? S 0:00 /usr/lib/lpd
root 293 0.0 3.0 1.34M 248K p1 S 0:01 - (csh)
root 100 0.0 1.6 1.36M 128K ? SW 0:02 /usr/etc/pbs
root 312 0.0 2.9 1.31M 240K p1 S 0:00 script next
root 102 0.0 1.3 1.34M 104K ? S N 0:00 /usr/etc/autodiskmount
root 0 0.0 16.7 14.3M 1.34M ? R N 49:43 (kernel idle)
next#
next# cat /etc/exports
#
/ -access=pc1:pc2:pc3:pc4:apollo
/clients/apollo -access=apollo,root=apollo
next#
next# cat /etc/fstab
#
/dev/sd0a / 4.3 rw,noquota,noauto 0 1
apollo:/id /Net nfs bg,rw,suid 0 0
next#
next# exportfs
/ -access=pc1:pc2:pc3:pc4:apollo
-------------------------------{From Apollo side}--------------------
# ps -e
PID TTY TIME COMMAND
1 ? 0:33 init
2 ? 236:01 null
3 ? 0:47 purifier
4 ? 0:00 purifier
5 ? 1:41 unwired_dxm
6 ? 0:00 pinger
7 ? 0:06 netreceive
8 ? 5:48 netpaging
9 ? 0:15 wired_dxm
10 ? 10:53 netrequest
122 ? 9:49 dm
97 ? 0:34 glbd
87 ? 1:39 tcpd
95 ? 0:01 llbd
92 ? 0:01 inetd
105 ? 0:05 mountd
103 ? 0:00 portmap
107 ? 1:51 nfsd
109 ? 0:02 pcnfsd
120 ? 0:01 mbx_helper
114 ? 0:03 spm
116 ? 0:00 netman
321 pad0002 0:01 sh
123 ? 0:00 siomonit
125 node_data/dev/ 0:00 siologin
320 pad0001 0:00 sh
322 ? 0:01 alarm_server
333 pad0002 0:17 stat
331 pad0002 0:00 sh
370 ? 0:00 tape
369 ? 0:07 slct
393 ttyp0 0:02 sh
371 pad0005 3:11 dbpr
372 pad0008 0:07 dbkp
373 pad0010 0:44 epcb
374 ? 0:01 csh
392 ? 0:02 telnetd
405 ttyp0 0:00 ps
# cat /etc/exports
//
# mount
/ on /dev/dsk/W0d0s1 rw on Mon Apr 8 12:56:14 1991cnh5730@maraba.tamu.edu (04/09/91)
In article <1991Apr9.015148.17946@leland.Stanford.EDU> tonytran@portia.Stanford.EDU (Tony) writes:
I mounted a remote Apollo file system successfully, but I am only
able to access the Apollo if I were the root on the Next.
and later says
Also, I trying mounting to the Next from the Apollo but is denied
access. It was working OK when the Next workstation was running
version 1.0b.
If you tried to export from the Apollo and mount onto the NeXT and can
only access the files system as root, you may wish to check the UID of
the directory(s) and file(s) on both systems. Do they "collide?"
If you are getting "access denied," (from the Apollo?), you may have a
problem with the exporter's /etc/hosts file. If any systems are
running Sun-style yellow pages, you need to get a new "make" on the
the yp-master.
hope this helps.
--
"Battle not with monsters, lest ye become a monster,
and if you gaze into the abyss, the abyss gazes also into you."
-Friedrich Wilhelm Nietszchenazgul@alphalpha.com (Kee Hinckley) (04/09/91)
In article <1991Apr9.015148.17946@leland.Stanford.EDU> tonytran@portia.Stanford.EDU (Tony) writes: >I mounted a remote Apollo file system successfully, but I am only >able to access the Apollo if I were the root on the Next. Interesting. I have a similar problem from a Sun to the Apollo. I can access it, but df only works if I'm root. I mounted //. Anyone have any ideas? I've also seen other things. The Sun hangs (^C breaks out of it) trying to run binaries stashed on the Apollo - or reading and writing large files. The error on the Apollo was something to the affect that a value was non-numeric. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (04/10/91)
In article <1991Apr9.015148.17946@leland.Stanford.EDU> tonytran@portia.Stanford.EDU (Tony) writes: >I mounted a remote Apollo file system successfully, but I am only >able to access the Apollo if I were the root on the Next. I assume your userids and groupids match properly (sounds like they should if you were running this before). >Also, I trying mounting to the Next from the Apollo but is denied >access. It was working OK when the Next workstation was running >version 1.0b. My first guess here is that you need the '-n' option on the 'mountd' commands in /etc/inetd.conf (Apollo does not have "Secure NFS"), so you must use unprivileged ports on the NFS server. Next probably upgraded their NFS between the releases. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
rmf@media.uucp (Roger Fujii) (04/10/91)
nazgul@alphalpha.com (Kee Hinckley) writes: >In article <1991Apr9.015148.17946@leland.Stanford.EDU> tonytran@portia.Stanford.EDU (Tony) writes: >>I mounted a remote Apollo file system successfully, but I am only >>able to access the Apollo if I were the root on the Next. >Interesting. I have a similar problem from a Sun to the Apollo. I can access it, but >df only works if I'm root. I mounted //. Anyone have any ideas? Check to see what that port numbers are when you do an /etc/rpcinfo. My recollection was that when one of the hosts allocated a port < 1024, for a nfs daemon, the apollo would fail because its nfs daemon was schitzoid (ran as the current user using it) and lost permission to the connecting port (<1024 are priveliged ports). >I've also seen other things. The Sun hangs (^C breaks out of it) trying to >run binaries stashed on the Apollo - or reading and writing large files. >The error on the Apollo was something to the affect that a value was >non-numeric. I seen this too. The apollo must be screwing up the SunOS's shared text mechanism over nfs. I wish apollo would implement the newer NFS protocol - it would get rid of some of these headaches. -- Roger Fujii - Media Cybernetics Phone: (301)495-3305 Internet: rmf%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!rmf
nazgul@alphalpha.com (Kee Hinckley) (04/12/91)
In article <1991Apr10.135826.26648@media.uucp> rmf@media.uucp (Roger Fujii) writes: >>Interesting. I have a similar problem from a Sun to the Apollo. I can access it, but >>df only works if I'm root. I mounted //. Anyone have any ideas? > >Check to see what that port numbers are when you do an /etc/rpcinfo. >My recollection was that when one of the hosts allocated a port < 1024, >for a nfs daemon, the apollo would fail because its nfs daemon was >schitzoid (ran as the current user using it) and lost permission to >the connecting port (<1024 are priveliged ports). I don't think that's it. It's port 2049. >>I've also seen other things. The Sun hangs (^C breaks out of it) trying to >>run binaries stashed on the Apollo - or reading and writing large files. >>The error on the Apollo was something to the affect that a value was >>non-numeric. > >I seen this too. The apollo must be screwing up the SunOS's shared text >mechanism over nfs. I wish apollo would implement the newer NFS protocol - >it would get rid of some of these headaches. Any comments from anyone at Apollo? This is a royal pain. I've got more disk space on my Apollo's than on my Sun, but I don't dare use it from the Sun because it's so unreliable. Accessing the Sun from the Apollo works fine though. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
joey@tessi.UUCP (Joe Pruett) (04/14/91)
I was able to finally get df to work for apollo filesystems accessed through NFS. All I had to to was create a group in the registry on the apollo. Looking at /usr/adm/nfs_error_log showed lots of "Unable to convert uid <uid>, gid 5 to a SID" messages. None of our users are in group 5 (operator), but I decided to create that group on the apollo, and everything started working. I don't know where the 5 is coming from, but as long as things work better I'm willing to live with the mystery.
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (04/14/91)
We too have added all the uids and gids from our SGI and IBM RS/6000 systems to the Apollo registry, and we don't see these NFS problems. Except that root on the Apollo can not do things on remote file systems unless root owns the remote file/directory, our NFS seems pretty good, given the flakiness/hesitations of TCP/IP on the DN10000. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775