Upgraded from 6.1.5 to 6.2.1 and now when I attempt to run splunk reload deploy-server I get this error message
D:\Splunk\bin>splunk reload deploy-server
Splunk username: <userid>
Password:
Could not write to auth token file '\\<server>\users\.splunk\authToken_<localservernamer>_8089'.
An unforeseen error occurred:
Exception: <type 'exceptions.WindowsError'>, Value: [Error 2] The system cannot find the file specified: '\\\\<server>\\users\\.splunk\\authToken_<localservernamer>_8089'
Traceback (most recent call last):
File "D:\splunk\Python-2.7\Lib\site-packages\splunk\clilib\cli.py", line 1145, in main
parseAndRun(argsList)
File "D:\splunk\Python-2.7\Lib\site-packages\splunk\clilib\cli.py", line 872, in parseAndRun
login({}, True)
File "D:\splunk\Python-2.7\Lib\site-packages\splunk\clilib\cli.py", line 213, in login
authToken = user_friendly_login(username, password, save=True)
File "D:\splunk\Python-2.7\Lib\site-packages\splunk\clilib\cli.py", line 160, in user_friendly_login
os.unlink(getAuthFilePath())
WindowsError: [Error 2] The system cannot find the file specified: '\\\\<server>\\users\\.splunk\\authToken_<localservernamer>_8089'
Please file a case online at http://www.splunk.com/page/submit_issue
Splunk found the cause. The newer version of python bundled with this version of splunk handled our environmental variables differently.
"I think we’re finally to the bottom of it. Splunk 6.x is packaged with a newer version of Python that handles Windows UNC paths differently. Before, building the file path with “\” would take you to the root of the file system or just “\”. Now Python recognizes that a path starting with “\” is a UNC path and so when you build the file path with “\” at the end it takes you to the root of the UNC mount which it expects to be at "\\”. That explains the difference."
The fix for use was this edit
In $SPLUNK_HOME\Python-2.7\Lib\site-packages\splunk\clilib\cli.py on line 1070 there is the following piece of code:
userHome = os.path.join(userHomePrefix, userHome)
Change it to the following and your .splunk directory
userHome = os.path.join(userHomePrefix, userHome.strip("\\"))
Splunk found the cause. The newer version of python bundled with this version of splunk handled our environmental variables differently.
"I think we’re finally to the bottom of it. Splunk 6.x is packaged with a newer version of Python that handles Windows UNC paths differently. Before, building the file path with “\” would take you to the root of the file system or just “\”. Now Python recognizes that a path starting with “\” is a UNC path and so when you build the file path with “\” at the end it takes you to the root of the UNC mount which it expects to be at "\\”. That explains the difference."
The fix for use was this edit
In $SPLUNK_HOME\Python-2.7\Lib\site-packages\splunk\clilib\cli.py on line 1070 there is the following piece of code:
userHome = os.path.join(userHomePrefix, userHome)
Change it to the following and your .splunk directory
userHome = os.path.join(userHomePrefix, userHome.strip("\\"))
Hello,
the error message may come a splunk command (with authentication ) which was launched from another user (automatically or manually) which wrote the file with another rights on it.
Is the file \\users.splunk\authToken__8089 existing ?
if this is the case, what if you rename it to .old and try again your command ?
can you create a file and later modify it in the same directory ( \\users.splunk) while logged with the same windows user (from a command line for example) ?
As a workaround, you could also try with a local home directory configured for your windows user by I guess this is not what you want to do.(there may be a pb with the way splunk uses the remote path. in 6.2..)
Hope that helps
This seems to be capturing the homepath of the user signed \\users\ but the .splunk\authToken__8089 file is in the root of 😧
I have opened a ticket with Splunk support but still no resolution.
After your 6.2.1 upgrade, did you have any issues with saved searches or saved alerts? It looks like I lost mine after the 6.2 upgrade.
We have had that problem before, we had saved searches and alerts within the app folder. The deployment server wiped out that data and re-wrote those directories from its source.
We copied those items to our deployment server so that it could be replicated out with the app.