Capture stopped with error "Error in ASM setup .... ORA-01031: insufficient privileges" (4244308)

Capture stopped with error: 12035 - OCISessionBegin failed with ORA-15000. [sp_ocap(osp)/5821]
Warning: Failed to open second Oracle connect for OPS thread. [sp_ocap/5821]
Error: Error in ASM setup: ASMsetup: ASMQuerySetup:OCIError OCI_ERROR, Code 1031: ORA-01031: insufficient privileges. [sp_ocap/6345]

or you may see the below error

Capture: Error opening file +RECO_XDHFD3/ecosp/archivelog/2015_10_10/thread_3_seq_17811.1367.892687399: ASMopen: ASMOciOpen: ASMQueryOpenViaDiskGroup_impl:HandleAllocate OCI_INVALID_HANDLE  (capturing from SPLEXSID) [module oct]

Following lists some of common causes of capture failing to read the redo/archive logs:

1. SharePlex binaries/files, Oracle binaries/files, and ASM instance binaries and disks are owned by different OS users and are in different OS groups.

2. The TWO_TASK environment variable was set

3.SharePlex OS user is Oracle, but Oracle user is not part of group who owns  ASM binary
Or Oracle user was not explicitly assigned to the group who owns ASM binary even though the group owner of ASM binary is a primary group of the Oracle user,

4. Wrong permissions on the oracle executable file.

5. The group for ASM disk does not have read permission on ASM disk while SharePlex binary owner is not oracle but belong to this group.

6. oratab file contains the wrong ORACLE HOME

Workarounds:
Resolution 1:

Make sure the SharePlex OS user is in the group who is a group owner of  ASM instance home (or regular Oracle database if the ASM and regular instances share same Oracle home).
.
For example, if asmadmin group is the group owner of  ASM home,  then add the SharePlex user to the asmadmin group in the /etc/groups file as below :

asmadmin:x:507:grid,oracle
Bounce the sp_cop.

Resolution 2:

Unset the TWO_TASK environment variable, and stop and start sp_cop without TWO_TASK exported

Resolution 3:

Add Oracle user who is owner of shareplex binary to the group who owns the ASM binary even though that group is a primary group of  Oracle user in the /etc/group file.  Also make sure the owner of the SharePlex binary is part of the asmadmin group.

For  Example, if the oninstall group is the group owner for ASM binary, add SharePlex OS user, in this example it is Oracle user to the oinstall group as below in the /etc/group file.

oinstall:x:503:oracle

Then bounce the sp_cop

Resolution 4:

The oracle executable file should have setuid bit like below:
$ cd $ORACLE_HOME/bin
$ ls -la oracle

-rwsr-s--x 1 oracle oinstall 96725724 Apr 2 13:43 oracle

If it’s not the same then issue the following command to set the correct permissions:

$ chmod 6751 oracle

Then bounce the sp_cop

Resolution 5:

Give the group Read permission to asm disks.

For example, if the asm disk is owned by oracle and group is oinstall then make sure oinstall has read permission and the SharePlex binary owner should be part of the oinstall group.

Resolution 6:

Make sure that ORACLE_HOME is set correctly in /etc/oratab and /var/opt/oracle/oratab.  NOTE: sometimes the oratab file will be in 2 locations, /etc and /opt.  Be sure to look in BOTH locations even if it's only supposed to reside in one.