Path: utzoo!attcan!uunet!lll-winken!quintro!bep
From: bep@quintro.uucp (Bryan Province)
Newsgroups: comp.sys.apollo
Subject: Re: create remote process
Message-ID: <1990Aug7.143621.1414@quintro.uucp>
Date: 7 Aug 90 14:36:21 GMT
References: <1147@fang.dsto.oz>
Reply-To: bep@quintro.UUCP (Bryan Province)
Organization: none
Lines: 26

In article <1147@fang.dsto.oz> agq@dstos3.dsto.oz (Ashleigh Quick) writes:
>   crp -on B -me
>
>which would fail with an error similar to
>  "cannot create rmeote process - no rights to server mailbox"
>
>.... but what causes the devices to get
>screwed up in the first place?
>
>Ashleigh Quick
>AGQ@dstos3.dsto.oz.au

The only explanation I have gotten is that it happens when you are logged in
as root and do a "cpr -on B -me" to another machine.  Take a look at the
protections on the /dev/crp* files on the machine.  They should be wide open
but after root gets a hold of them they get set so that only root can do
anything with them.  The strange thing is that root can't crp on either after
this has happened.  Instead of running /etc/mkdev you could also just change
the rights of the /dev/crp* files.  The way to avoid the problem is to avoid
doing a "crp -on B -me" when logged in as root.  If you do this check the
protections of the crp files of machine B after disconnecting.
-- 
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Bryan Province     Glenayre Corp.           quintro!bep@lll-winken.llnl.gov
                   Quincy,  IL              tiamat!quintro!bep@uunet
           "Surf Kansas, There's no place like home, Dude."