ORA-12546: TNS:permission denied after moving to new server

[Genericus]

NetBackup 7.5.0.3 on Solaris 10

Have an existing Solaris Cluster with several servers, four Oracle DB.

All backups run fine, using rman scripts. Policy call basic script which checks the server name, then updates the policy variable so it selects the child policy with the storage for direct backups via fiber. Has worked fine for many years.

Added new server, so I updated the scripts to include possibility of more server names. After cluster failover to new server, of the four DB, three run fine, archive and DB, the fourth gives me the ORA-12546: TNS:permission denied error when run from NB, or as root from the server. When run as oracle by running the script, it works fine.

I checked the externaljob.ora files, they are the same for all 4 DB.

Let me know what you want to see, essentially, the parent scripts work fine, the child jobs fail.

14:14:40.898 [3059] <4> bphdb: INF - Processing /ORASCORE/opt/app/oracle/rman/ORASCORE_arch_edl.sh
14:14:40.899 [3059] <4> bphdb: INF - Waiting for the child status
14:14:40.901 [3060] <4> bphdb: INF - Child executing /ORASCORE/opt/app/oracle/rman/ORASCORE_arch_edl.sh
14:14:46.900 [3059] <16> bphdb: ERR - Script exited with status = 1 <the requested operation was partially successful>
14:14:46.900 [3059] <16> bphdb: ERR - bphdb exit status = 6: the backup failed to back up the requested files

14:14:46.900 [3059] <4> bphdb: INF - EXIT STATUS 6: the backup failed to back up the requested files

[Yasuhisa_Ishika]

Review your backup script to determine in which user account 'rman' command is kicked, and check if this user have sufficient privilege on that server. If you does not switch user by 'su' command in your script, root user is used.

this error is occured in Oracle, and it is mostly matter of Oracle so you should ask your DB admin for further assistance.

[Marianne]

I agree with Yasuhisa.

Check the backup script: search for the 'su - <oracle-user>' in the script and ensure that correct oracle user name is specified.

Extract from sample script:

# Replace ora81, below, with the Oracle DBA user id (account).
# ---------------------------------------------------------------------------

ORACLE_USER=ora81
........

if [ "$CUSER" = "root" ]
then
    su - $ORACLE_USER -c "$CMD_STR" >> $RMAN_LOG_FILE
else
    /usr/bin/sh -c "$CMD_STR" >> $RMAN_LOG_FILE

[Michael_G_Ander]

As the script works with the oracle user, I would check that the parent script contains a switch user to oracle before calling rman, something like su - oracle -c "rman script"

The rman message log might contain more information about the ORA-12546 error, the oracle alert log is also a place to look.

I would also create the dbclient log with 777 permission as this often gives clues too

Hope this helps

[Genericus]

The scripts run as root, the su - oracle line is commented out.

When I stepped through the scripts, loading the environment variables, the working scripts allowed me to export my ORA_variables, and manually run the command "rman nocatalog"

The working one connects successfully from the RMAN> prompt

using "connect target rcat/rcat@ORACLE_SID"

The one that fails, responds

RMAN> connect target rcat/rcat@ORACLE_SID

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

ORA-12546: TNS:permission denied

RMAN> quit

thoughts?

[Marianne]

 When run as oracle by running the script, it works fine.

 The scripts run as root, the su - oracle line is commented out.

Put back su - oracle in the script.

root in this environment  clearly does not have dba permissions.

This is perfectly normal - every single installation that I have ever been involved with needed the 'su - <oracle-user>'

[Yasuhisa_Ishika · Accepted solution]

If backup script is identical on other hosts, and backup works fine with root user, some settings related to DB privilege for root is mot identical on this host. Please ask your DBA to check if provilege for root user is identical or not.  I suppose root user is member of dba group on other hosts but not on this new host.

[Genericus]

The challenging part is that the root user is used on all four DB on this system, and three work. 

Essentially, how does a system wide root user work on 3 and not on the 4th?

What can be set on the DB to allow a user access? 

[Genericus]

Issue was solved by adding root to the dba group on the server. This was not immediately seen, it also required NetBackup media server recycle. After netbackup restart, jobs ran fine.

Thanks for your help.