op version two can't 'get' certain records

ftpd
ftpd
Community Member

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

  • Hi @ftpd:

    Thanks for reaching out about this! To clarify, when you say some-id, do you specifically mean the UUID of an item, or the name you've given it? Let me know.

    Jack

  • ftpd
    ftpd
    Community Member

    Both. I've tried with UUID and with the name (in "" if it contains spaces, of course).

  • 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

  • ftpd
    ftpd
    Community Member

    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?

  • Hey @ftpd:

    Emailing us from your 1Password account email would be best, thanks! 🙂

    Jack

  • ftpd
    ftpd
    Community Member

    Consider it done! Thanks again for your quick reply.

  • You're very welcome! We'll be in touch soon!

    Jack

  • 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. Does cat ~/.op/config or cat ~/.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.

  • ftpd
    ftpd
    Community Member
    edited January 2023

    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 by op 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.

  • 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.

  • ftpd
    ftpd
    Community Member

    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!

  • 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!

This discussion has been closed.