Re: ORA-01031: insufficient privileges

Neil,

none of your hints bites. I'm facing a standard installation with runInstaller and dbassist and I'm locked out!!!!

Any further hints?

Helplessly

Manfred

NeilC wrote:

> Hi,
>
> Check the following:
>
> SQLNET.ORA:
> ===========
> check your sqlnet.ora file is not corrupted or has certain security
> features enabled. If you aren't using database links then comment out
> the line SQLNET.AUTHENTICATION_SERVICES or try setting it to:
> SQLNET.AUTHENTICATION_SERVICES = (BEQ,NONE)
>
> check that SQLNET.CRYPTO_SEED is not set in sqlnet.ora If it is,
> comment the line out.
> If AUTOMATIC_IPC is set to "TRUE" it can force a "TWO_TASK" connection.
> Try setting this to false: AUTOMATIC_IPC = FALSE
>
> Set the permissions correctly in the "TNS_ADMIN" files. The environment
> variable TNS_ADMIN defines the directory where the "sqlnet.ora",
> tnsnames.ora", and "listener.ora" files reside. These files must contain
> the correct permissions, which are set when "root.sh" runs during
> installation.
>
> Software and Operating System Issues:
> =====================================
> Be sure $ORACLE_HOME is set to the correct directory.
>
> Check that $ORACLE_SID is set to the correct SID, (including
> capitalization), and does not have any typos.
>
> Ensure $TWO_TASK is not set.
>
> Make sure the operating system user issuing the CONNECT INTERNAL belongs
> to the "osdba" group as defined in the "$ORACLE_HOME/rdbms/config.s" or
> "$ORACLE_HOME/rdbms/config.c". Typically this is set to "dba".
> To verify the operating system groups the user belongs to, do the
> following:
> % id
> % uid=1030(oracle) gid=1030(dba)
>
> The "gid" here is "dba" so the "config.s" or "config.c" may contain an
> entry such as:
> /* 0x0008 15 */ .ascii "dba\0"
> If these do not match you will either need to add the operating system
> user to the group as it is seen in the "config" file, or modify the
> "config" file and relink the "oracle" binary.
>
> Check the permissions on the Oracle executable:
> % cd $ORACLE_HOME/bin
> % ls -l oracle ('ls -n oracle' should work as
> well)
> The permissions should be rwsr-s--x, or 6751.
> If the permissions are incorrect, do the following as the "oracle"
> software owner:
> % chmod 6751 oracle
>
> Verify that the file system is not mounted no set uid:
> % mount
> /u07 on /dev/md/dsk/d7 nosuid/read/write
> If the filesytem is mounted "nosuid", as seen in this example, you will
> need to unmount the filesystem and mount it without the "nosuid"
> option.
>
> Verify that the "osdba" group is only listed once in the "/etc/group"
> file:
> % grep dba /etc/group
> % dba::1010: dba::1100:
> If more than one line starting with the "osdba" group is returned you
> will need to remove the ones that are not correct. It is not possible to
> have more than one group use a group name.
>
> HTH
>
> NeilC
>
> Manfred Sturm wrote:
> >
> > Nope. Same result: ORA-01031: insufficient privileges
> >
> > Thx
> >
> > Manfred
> >
> > NetComrade wrote:
> >
> > > connect internal/oracle
> > >
> > > On Thu, 16 Dec 1999 18:08:48 +0100, Manfred Sturm
> > > <Manfred.Sturm_at_itServe.ch> wrote:
> > >
> > > >This is a multi-part message in MIME format.
> > > >--------------4603F4F057A5CEDC03C520C7
> > > >Content-Type: text/plain; charset=us-ascii
> > > >Content-Transfer-Encoding: 7bit
> > > >
> > > >Hi
> > > >
> > > >I'm not able to dbshut/dbstart my 3 successfully instances of my
> > > >Oracle8i (8.1.5.0.0 for Solaris7) installation anymore. Trying to
> > > >connect using svrmgrl with my Oracle installation user (named: oracle8i,
> > > >member of groups: dba,oinstall,oper) using
> > > > SVRMGR> connect internal
> > > > Password:
> > > > ORA-01031: insufficient privileges
> > > >a password, I never have been prompted for. Neither 'manager' nor
> > > >'change_on_install' works.
> > > > SVRMGR> connect / as sysdba
> > > > ORA-01031: insufficient privileges
> > > >pretty much the same result here.
> > > >
> > > >Note: I expect to be able to log in internally to the currently set
> > > >ORACLE_SID database instance. I intent to use OS authentication with
> > > >remote_login_passwordfile set to none and a removed
> > > >$ORACLE_HOME/dbs/orapw<ORACLE_SID> file (I did this modification while
> > > >the particular db instance was shut down).
> > > >
> > > >I try to find a way to use OS authentication with no password for the
> > > >internal user, so dbstart/dbshut work unchanged for a UNIX user being
> > > >member of the dba or oper group (as described in the administration
> > > >manual).
> > > >
> > > >But for now it seems I have locked myself out of the system for
> > > >startup/shutdown or database manipulation operations.
> > > >
> > > >P.S.: user sys/change_on_install and system/manager still work fine :-|
> > > >
> > > >Who can help me out?
> > > >
> > > >Cheers
> > > >
> > > >Manfred
> > > >
> > > >--------------4603F4F057A5CEDC03C520C7
> > > >Content-Type: text/x-vcard; charset=us-ascii;
> > > > name="Manfred.Sturm.vcf"
> > > >Content-Transfer-Encoding: 7bit
> > > >Content-Description: Card for Manfred Sturm
> > > >Content-Disposition: attachment;
> > > > filename="Manfred.Sturm.vcf"
> > > >
> > > >begin:vcard
> > > >n:Sturm;Manfred
> > > >tel;fax:031 305 16 17
> > > >tel;work:031 305 16 19
> > > >x-mozilla-html:FALSE
> > > >org:itServe AG
> > > >version:2.1
> > > >email;internet:Manfred.Sturm_at_itServe.ch
> > > >title:Software Engineer
> > > >adr;quoted-printable:;;L=E4nggass-Strasse 26=0D=0APostfach 690=0D=0A3000 Bern 9;;;;
> > > >x-mozilla-cpt:;9744
> > > >fn:Manfred Sturm
> > > >end:vcard
> > > >
> > > >--------------4603F4F057A5CEDC03C520C7--
> > > >
> > >
> > > In case I forgot to mention:
> > > We use Oracle 7.3.4 on Solaris 2.6, 2.7 boxes
> > > ---------------
> > > Andrey Dmitriev eFax: (978) 383-5892 Daytime: (917) 750-3630
> > > AOL: NetComrade ICQ: 11340726 remove NSPAM to email

Received on Mon Dec 20 1999 - 08:59:51 CST