Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
paulpharr
4 years agoOccasional Contributor
CLI 2.0 file permissions recommendations
in looking at our server logs after switching some access to go through CLI 2.0, I see the following error output on most calls:
couldn't start daemon: open /run/user/0/op-daemon.pid: permission d...
andi_t_1P
1Password Team
4 years agoHi paulpharr, @samarthj. Coming back at investigating this issue, it seems like op tries to open/create a path you do not have access to, thinking op-daemon.pid will be found there (e.g /run/user/0/op-daemon.pid). It does that in order to start-up the daemon process that is generally responsible for caching, but also for expired session file cleanup, which is why it needs to be running on every command invocation, hence, the ever present error message.
Now, there are 2 places where op-daemon.pid could be located. Most often it will be located in the temp folder ($TMPDIR), but for you this seems not to be the case. The 2nd place where it could be located is the path specified through $XDG_RUNTIME_DIR. This latter case happens if and only if $XDG_RUNTIME_DIR env var is set at the time of command execution.
I would suggest the following line of thought:
Echo your $TMPDIR. Is it the same with the path output in the error? If yes, then to overcome this issue you would need to set the $TMPDIR to a path you know for sure that you have access to on your machine. If no (this is where I'd place my bet), most likely somewhere along the way $XDG_RUNTIME_DIR gets modified to a path you do not have access to, so you need to remove that side-effect from your environment.
(It is also possible that your $TMPDIR gets altered somewhere in the process, but this is extremely unlikely imo.)
Would love to hear back from you regarding this issue and what these instructions uncovered for your use cases.
Until then all the best,
Andi