I have been working a lot with EUS lately at a big customer. My personal account is able to login to databases (EUS) and also on to OEL (OAS4OS). This combined with some chown/chmod commands on OEL enables me to do my job with my personal account.
Since this customers also uses ASM, I figured I would like to use my personal account for asmcmd too. First I tested the process with a local account, baby steps usually works best for me. I created an account jhl
# useradd -g asmadmin -G dba jhl
Next i su’d to jhl and tested the procedure:
$ id
uid=10238(jhl) gid=4007(asmadmin) groups=4006(dba),4007(asmadmin)$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm_200 is /u01/app/oracle$ asmcmd
ASMCMD> ls
This looks promising, all needed to be done next was repeating the steps only now with an account from the OID. First I had to add the group to the OID, here’s the ldif I used:
cn=asmadmin,cn=groups,dc=some_company,dc=nl
uniquemember=cn=landlustjh,cn=users,dc=some_company,dc=nl
owner=cn=orcladmin,cn=users, dc=some_company,dc=nl
objectclass=top
objectclass=groupOfUniqueNames
objectclass=orclGroup
objectclass=posixgroup
cn=asmdba
orclisvisible=true
displayname=asmadmin
description=asmadmin
gidnumber=1007
As you can see in the ldif, I added my personal account to the asmadmin group. After adding the group to the OID I performed a quick check to see if all went according to plan:
$ id
uid=10217(LandlustJH) gid=1006(dba) groups=1006(dba),1007(asmadmin),1010(remotelogin),1011(oraclemembers),1012(rootmembers)
Now te login:
$ asmcmd
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
ASMCMD>
Aiks? Since I’m not that stupid, I started tracing asmcmd:
$ export DBI_TRACE=1
$ asmcmd
-> DBI->connect(dbi:Oracle:, , ****, HASH(0xd547e0))
-> DBI->install_driver(Oracle) for linux perl=5.008003 pid=6683 ruid=10217 euid=10217
install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_202//perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
<- install_driver= DBI::dr=HASH(0x7c28c0)
ERROR: 1034 ‘ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)’
<- DESTROY= undef at DBI.pm line 591
DBI connect(”,”,…) failed: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
The tracing and some MOS-ing (MOS actually works for me!) learned me that I forgot to set my environment. No rocket science to far. Let’s retry:
$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm_200 is /u01/app/oracle$ asmcmd
-> DBI->connect(dbi:Oracle:, , ****, HASH(0xd53960))
-> DBI->install_driver(Oracle) for linux perl=5.008003 pid=3186 ruid=10217 euid=10217
install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
<- install_driver= DBI::dr=HASH(0x7c1e70)
ERROR: 12547 ‘ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)’
<- DESTROY= undef at DBI.pm line 591
DBI connect(”,”,…) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)
ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
ORA-12547 was NOT wat I was expecting at all. Even more MOS-ing later I discovered the privileges on the oracle binary were not set correctly. This could be fixed easily
oracle$ chmod 6751 $ORACLE_HOME/bin/oracle
and then yet another try (now with the proper environment):
$ asmcmd
-> DBI->connect(dbi:Oracle:, , ****, HASH(0xd53990))
-> DBI->install_driver(Oracle) for linux perl=5.008003 pid=31109 ruid=10217 euid=10217
install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
<- install_driver= DBI::dr=HASH(0x7c1ec0)
ERROR: 1031 ‘ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)’
<- DESTROY= undef at DBI.pm line 591
DBI connect(”,”,…) failed: ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
ORA-01031? Now how about that? Usually that’s caused by password file trouble:
SQL> select * from v$pwfile_users;
USERNAME SYSDBA SYSOPER SYSASM
—————- ————— ————— —————
SYS TRUE TRUE FALSE
SQL> grant sysasm to sys;Grant succeeded.
SQL> select * from v$pwfile_users;USERNAME SYSDBA SYSOPER SYSASM
————— ————— ————— —————
SYS TRUE TRUE TRUE
Now lets’ try again:
$ asmcmd
-> DBI->connect(dbi:Oracle:, , ****, HASH(0xd539b0))
-> DBI->install_driver(Oracle) for linux perl=5.008003 pid=4315 ruid=10217 euid=10217
install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
<- install_driver= DBI::dr=HASH(0x7c23c0)
ERROR: 1031 ‘ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)’
<- DESTROY= undef at DBI.pm line 591
DBI connect(”,”,…) failed: ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
Still no jackpot, but guess what:
$ asmcmd -a sysdba
-> DBI->connect(dbi:Oracle:, , ****, HASH(0xd539b0))
-> DBI->install_driver(Oracle) for linux perl=5.008003 pid=4351 ruid=10217 euid=10217
install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
<- install_driver= DBI::dr=HASH(0x7c23c0)
1 <- prepare(‘
SELECT SYS_CONTEXT(‘userenv’,'session_user’) FROM DUAL
‘ undef)= DBI::st=HASH(0x100a6e0) at Oracle.pm line 295
<- selectrow_array(‘
SELECT SYS_CONTEXT(‘userenv’,'session_user’) FROM DUAL
‘)= ‘SYS’ at Oracle.pm line 295
$h->{‘ora_session_mode’}=2 ignored for invalid driver-specific attribute
<- connect= DBI::db=HASH(0xfa15d0)
1 <- FETCH(‘NAME’)= [ 'VALUE' ] at asmcmdshare.pm line 2324
1 <- fetch= [ 'asm' ] row1 at asmcmdshare.pm line 2324
1 <- FETCH(‘NAME’)= [ 'VERSION' ] at asmcmdshare.pm line 2324
1 <- fetch= [ '11.1.0.7.0' ] row1 at asmcmdshare.pm line 2324
ASMCMD>
hey joe, what do you know? I only found this behaviour once, when the osdba group was not called dba. I remember that I had to check some spec file and recompile ioracle:
cat $ORACLE_HOME/rdbms/lib/config.c
#define SS_DBA_GRP “dba”
#define SS_OPER_GRP “dba”
#define SS_ASM_GRP “asmadmin”
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
Sadly enough in this case the default group name is asmadmin, so a recompile will not help me out. The only thing left is to trace the sqlnet session from asmcmd to the database back to OID, but somehow I have a feeling this will not help me out. Anyway, I’m done for the day. Maybe I can find a solution tomorrow. Any help is appreciated.
