Why am I getting error "Unable to locate secret used to encrypt/decrypt passwords for identities" after installing Splunk DB Connect?

[vinchakov_a]

I received this error after installing Splunk DB Connect:

04-16-2015 16:06:54.035 +0300 ERROR AdminManagerExternal - Stack trace from python handler:\nTraceback (most recent call last):\n  File "/opt/splunk/lib/python2.7/site-packages/splunk/admin.py", line 67, in init\n    hand = handler(mode, ctxInfo)\n  File "/opt/splunk/etc/apps/splunk_app_db_connect/bin/rh_identities.py", line 24, in __init__\n    self.verifySecretPath()\n  File "/opt/splunk/etc/apps/splunk_app_db_connect/bin/rh_identities.py", line 28, in verifySecretPath\n    raise Exception("Unable to locate secret used to encrypt/decrypt passwords for identities")\nException: Unable to locate secret used to encrypt/decrypt passwords for identities\n

04-16-2015 16:06:54.035 +0300 ERROR AdminManagerExternal - Unexpected error "<type 'exceptions.Exception'>" from python handler: "Unable to locate secret used to encrypt/decrypt passwords for identities".  See splunkd.log for more details.

[sylim_splunk]

This file, being used in ver 2.x & 3.x, is used to encrypt the passwords. If the file has been deleted there is no way to read the passwords. You need to check if you find a copy of it for example from a back up or if it has been copied to another node (typically in a search head cluster configuration). If this file is definitely lost, the passwords need to be re-entered.

[alasreeram]

I have this problem too in splunk v6.3 and db connect 2 v2.0.6.

[Flynt]

Can you verify that the splunk.secret file exists in the $SPLUNK_HOME/etc/auth directory and the user that Splunk started with has read permissions?

[rmenon7]

I am getting this issue in DB connect app ... I checked and confirmed that there is a secret file that is present in .$SPLUNK_HOME/etc/auth .

Any idea why I could still be getting the error ?

[jagadeeshm]

How did you resolve this ?

[anthony_engelst]

I had this as well running an older 6.2.1 version of Splunk, upgrade to 6.2.2 seemed to fix the issue, but it's unclear if that's a side effect of the upgrade or something actually required with 6.2.2