CLI 2.0 file permissions recommendations

Hi 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

Hey all,

I will be filing an internal issue for investigating this error.

You say that it should be owned by the onepassword-cli group, which it is not.

This only applies on Linux where, indeed, the installer takes care of this aspect.

I am having the same issue on macos. All versions of linux I am running on are just fine.

Even without using cache the error is ever present. I literally get it on op help. I have tried to remove it from the system and reinstall, no dice.

You say that it should be owned by the onepassword-cli group, which it is not. Does that still hold for macos? And if it does, that is something the installer should be doing right?

Regardless I tried it and it doesn't work. Incidentally it is also missing the kernel secure permission, which doesn't help either.

Hi paulpharr, thanks for reaching out!

The most common use case for the daemon is caching. Are you passing --cache to your commands?

does not affect the functionality - all calls are working afaict

When the daemon cannot be reached for caching purposes, the CLI continues without using the cache (re-fetching the items from 1Password servers).

im sure this is related to some installation/execution permissions differences yet to be investigated

There are some installation differences between 1Password CLI version 1 and 2. Most notably, version 2 is/should be owned by the onepassword-cli group. You can validate this using ls -l $(which op).

I realize it has been a month since you reached out about this. Have you been able to investigate and possibly remediate your installation? I'm curious if you have any findings, as I think we should improve the error message we're providing in case there's installation changes you should be making to remediate this.

Cheers,
Simon
Developer, Developer Products