RE: can't connect '/ as sysdba'

  • From: "Donahue, Adam" <Adam.Donahue@xxxxxxxxx>
  • To: <janine@xxxxxxxxxx>, "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 8 Dec 2006 10:04:52 -0500

Just to summarize the basics, the following is all true, Janine?

*       ORACLE_SID is set to the correct sid (although / as sysdba
simply connects to an idle instance if not).
*       ORACLE_HOME is set to the correct ORACLE_HOME.
*       PATH includes the correct $ORACLE_HOME/bin, and it's finding it
before any other (do a which sqlplus to check on modern shells that it's
finding the right version).
*       LD_LIBRARY_PATH is consistent with your ORACLE_HOME setting (to
be safe).
*       The group in config.s is set to your OSDBA group.
*       The oracle binary is running with the correct group (meaning any
change to config.s has been recompiled into that binary).  

                NOTE: ** This is a bug related to this on Oracle10gR2 on
Solaris (x86).  The Oracle Installer ignores the user's OSDBA/OSOPER
settings during installation, fixing it to dba.
                To fix in our environment, we patch with these diffs:

                        < .LV13:        .string "dba"
                        > .LV13:        .string "oradba"
                        < .LV12:        .string "dba"
                        > .LV12:        .string "oradba"

                        < NOKPIC_ASFLAGS=
                        > NOKPIC_ASFLAGS=-xarch=amd64

                And then 

                        make -f config.o ioracle

*       Connected to the user you want to use, the id command returns
the correct OSDBA group in its output.

With these settings correct, sqlplus should work.

If not, then something may be happening on the OS-level.  From the look
of your prompt, I'll make a guess you're running Linux.  (Sorry to hear
that.)  I believe there are some /etc/group limitations here - are you
using /etc/group?  If not, how is group membership determined?  You may
want to write a small C program to print out the user's groups, or do
further testing.

For the record, I don't believe / as sysdba has anything to do with the
orapw file, or the setting of remote_password_file {sp,}init.ora
variable (indeed - if the instance isn't running, it couldn't check this


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Janine Sisk
Sent: Wednesday, December 06, 2006 5:14 PM
To: Oracle-L Freelists
Subject: can't connect '/ as sysdba'

I'm still googling for answers but it's looking like I won't be  
finding one, so time to ask here.

I am working as a consultant with a installation.  I was  
present when it was installed and didn't see anything out of the  
ordinary happen.  It seems to function normally with one exception -  
no matter what I do, I get an ORA-01031 "Insufficient privileges"  
error when I try to connect with '/ as sysdba', which prevents  
dbstart and dbshut from working.  I have worked with other 9i  
installations and have never had this problem before.

Most of the suggestions boil down to making sure that group  
assignments are correct and that TWO_TASK is not set, and I've  
followed up on both of those.  The group that owns all of the files  
in $ORACLE_HOME is the same one that's set in config.c and is the  
oracle user's primary group.  I am only expecting this to work as the  
oracle user.

What else could be wrong?




This message may contain confidential, proprietary, or legally privileged 
information. No confidentiality or privilege is waived by any transmission to 
an unintended recipient. If you are not an intended recipient, please notify 
the sender and delete this message immediately. Any views expressed in this 
message are those of the sender, not those of any entity within the KBC 
Financial Products group of companies (together referred to as "KBC FP"). 

This message does not create any obligation, contractual or otherwise, on the 
part of KBC FP. It is not an offer (or solicitation of an offer) of, or a 
recommendation to buy or sell, any financial product. Any prices or other 
values included in this message are indicative only, and do not necessarily 
represent current market prices, prices at which KBC FP would enter into a 
transaction, or prices at which similar transactions may be carried on KBC FP's 
own books. The information contained in this message is provided "as is", 
without representations or warranties, express or implied, of any kind. Past 
performance is not indicative of future returns.

Other related posts: