op version two can't 'get' certain records
Hi.
I'm trying to migrate from op CLI v1 to v2, but I've encountered this problem, that some records aren't recognized.
I'm sourcing a 'script' with lines like:
export TF_VAR_some_password="$(op2 item get --cache --fields password some-id)"
and it works for the half of my records - 19 are fine, 19 are not. The 'failed' records are always the same. It looks like that:
$ op2 item get good-id ID: good-id Title: <redacted title> Vault: RedactedVault (<redacted-id>) Created: 1 year ago Updated: 1 year ago by <redacted-name> Favorite: false Tags: prod,rds Version: 1 Category: LOGIN Fields: username: <redacted-data> password: <redacted-data> $ op2 item get bad-id [ERROR] 2023/01/16 10:54:13 (404) Not Found: The requested resource was not found.
It works fine with 1Password CLI client version 1, both good-id and bad-id produce a valid json with my data.
Versions:
$ op2 --version 2.12.0 $ op --version 1.12.4
Any ideas, what I'm missing here?
1Password Version: 8.9.13
Extension Version: -
OS Version: Gentoo Linux, kernel 6.1.4
Browser:_ -
Comments
-
Both. I've tried with UUID and with the name (in "" if it contains spaces, of course).
0 -
Hi @ftpd:
Thanks for confirming. In that case, could you please reach out to us directly at
support+forum@1password.com
? Include your username:ftpd
and a link to this thread:https://1password.community/discussion/136950/op-version-two-cant-get-certain-records#latest
. Mention the trouble you're having, and we'll be able to take a closer look there. Thanks!Jack
0 -
Sure, @Jack.P_1P. Should I do it from an e-mail associated to my 1Password account I'm having this problem on, or it doesn't really matter?
0 -
Consider it done! Thanks again for your quick reply.
0 -
You're very welcome! We'll be in touch soon!
Jack
0 -
Hi @ftpd, I'm sorry you're running into issues while migrating!
One thing that comes to mind that's also different between CLI v2 series and in v1 you had to configure accounts specifically for the CLI, independent of your accounts configured in 1Password 8. If you have the "Connect with 1Password CLI" configuration turned on, v2 will use the accounts configured in 1Password 8.
In case the item with "bad-id" is stored in an account configured in
~/.op/config
, but not in 1Password 8, that could explain the behavior you're running into.Could you check the following to determine if you're in this situation:
1. Do you have "Connect with 1Password CLI" in the 1Password 8 settings turned on?
2. When searching for "bad-id" in 1Password 8, do the results include the item you're looking for?
3. Doescat ~/.op/config
orcat ~/.config/op
include any accounts that are not configured in 1Password 8? Please don't paste the output here directly, or redact the entries for "accountKey". This is your secret key that only you should know.0 -
Hi @simon_1P, thanks for your reply.
My
op
is not linked in settings - the documentation here: https://developer.1password.com/docs/cli/about-biometric-unlock/ says it's optional. I've added my account byop account add
command and the config file in~/.config/op/config
looks fine.
Actually, I would like to stick to this configuration, as configuration via Polkit etc. can be troublesome for less technical people in my organization.When I search bad-id (by UUID) in 1Password 8, I see the record just fine. Please note: all my records are stored in this account (in the same vault) and part of them works and part doesn't.
0 -
Okay, thank you for quickly ruling out the account configuration as possible culprit. Jack is continuing investigation into this inconsistency via the email thread you've started.
0 -
For anyone searching for similar issue in the future: 1Password Support Team was able to find a root cause of this:
"There seems to be an issue where if the user who has most recently edited an item is deleted, when 1Password CLI attempts to create the human readable version of the item info (which is done when using
op item get
for all situations other than using JSON format, even if all of the human readable version is not displayed), it tries to resolve the User's UUID to get their name. Because the user that most recently edited this item no longer exists, this results in 1Password CLI being unable to resolve the user and the error is shown.I've filed an issue internally to see if we can get this sorted out in the future."
And it matches my case - most (or even all?) of records I've checked and marked as 'not working' were created by a team member who left the company and his account was deleted from the organization. My current workaround is getting the data in JSON format and parsing them with
jq
to retrieve the string I need.Thank you @Jack.P_1P, @simon_1P and anyone else from your team involved in this ticket!
0 -
Great find! That's a case we hadn't thought about when implementing. Thanks for tracking this down with Jack!
And another thanks for following up here. Especially your workaround will be useful in case anyone is reading along who is running into the same.
Cheers!
0