Unable to fetch blob - after successful login/sync

[altercation]

Platform: Arch Linux 3.17.1 Package: tested both lastpass-cli and lastpass-cli-git from AUR (lpass -v reports LastPass CLI v0.3.0)

Login reports success (master password is entered, yubikey prompt received, OTP entered via yubikey, successful login message shows in terminal).

'lpass sync' returns 0 exit status (no other success/failure message)

The ~/.lpass directory shows blob and other expected files, all of non-zero size, so it looks like there was a good initial sync (this is actually the case after login even without running the explicit sync).

However running any lpass command (lpass ls) results in the error "Error: Unable to fetch blob. Either your session is invalid and you need to login with lpass login, you need to synchronize, your blob is empty, or there is something wrong with your internet connection."

I've tried to explicitly set env variables such as LPASS_HOME to make sure it was looking in .lpass (it was) and have logged out and in several times to test. Results are the same each time. Successful login and unsuccessful subsequent commands.

Logout is successful.

I've also tested disabling the agent, pinentry, via the appropriate env. variables with no change in this error condition.

I note that in my lastpass account settings, if I use the --trust option upon login I do not see the device listed in the trusted devices in my account. I have tested with and with --trust during login and this error is the same each time.

[bcopeland]

what about --sync=no after login (which should only look at the local blob)?

[altercation]

Consolidating my comments here:

1. good login
2. tested lpass ls --sync=no : same error
3. currently testing this with and without active agent. I note that the .lpass/agent.sock is present regardless of the value of LPASS_AGENT_DISABLE, though I assume that is unrelated.
4. ~/.lpass/blob is > 600k after initial (good) login, so network connectivity and sync seems to work, but lpass is erroring out on finding the blob in subsequent commands.
5. I also tested with a recursive chmod to a+rwx on .lpass and no luck.

[dirkvm]

Same problem here on Debian/Ubuntu.

lastpass_get_blob_version in blob_get_latest returns 0 causing the function to ignore the local blob.

login_check.php returns the following xml on my system: <?xml version="1.0" encoding="UTF-8"?>

[bcopeland]

Well it's clear we need a better message in any case.

@dirkvm what 2fa are you using? care to send me your login details so I can check it out on the server? (copeland@lastpass.com)

EDIT: I mean just username only

[bcopeland]

@altercation same questions to you. If you send me your username privately I can check whether it's related to your configuration.

[bcopeland]

In dirkvm's case we tracked this down to omnikey (smartcard authentication) being enabled which isn't supported in lastpass-cli, so disabling that is a thing to try for anyone in the same boat. Also we modified the server to not spit out an invalid/confusing error message in this case.

[altercation]

@bcopeland I'll message you privately as well with username, but I'm not seeing omnikey options (to disable) in lastpass prefs. Could you give me a pointer towards that option to disable.

I should also note that I have the lastpass binary component installed here, prior to/separately from lastpass-cli.

[bcopeland]

altercation and I worked this out offline -- it seems different errors can manifest in the same way. At any rate, I pushed 46e507dd361a6c57402b7d783e431dec9bea56e7 to fix and will close this. Anyone still experiencing this should open a new issue.