Keyring not implemented error (Crostini under ChromeOS)

Community Member


I'm trying to get 1Password working in the linux VM built into ChromeOS (Crostini). The app mostly works but it's unable to use system authentication and the SSH agent doesn't work. In the logs I can see the following error indicating it can't use the keyring:

WARN  2022-10-30T12:52:36.957 tokio-runtime-worker(ThreadId(11)) [1P:foundation/op-linux/src/] failed to initialize keyring helper, its functionality will be unavailable: KeyringError(Os { code: 38, kind: Unsupported, message: "Function not implemented" })
WARN  2022-10-30T12:52:36.957 1Password Application Keyring Manager(ThreadId(18)) [1P:foundation/op-linux/src/] 1Password's application keyring failed to initialize (KeyringError(Os { code: 38, kind: Unsupported, message: "Function not implemented" })), its functionality will be unavailable

I have gnome-keyring set up along with libsecret. The default login keyring unlocks automatically at boot. It works correctly with VSCode and the keyring-rs example CLI.

Polkit is also set up correctly and works for pinentry, password entry, etc.

Note that I am not trying to get 1Password in the VM to work with the 1Password extension on the host! I just need the 1password-cli and the ssh-agent to work inside of the VM.

Any idea what is causing the error?

1Password Version: 8.9.4
Extension Version: 2.4.1
OS Version: Debian 11 Bullseye
Browser:_ Chrome


  • destructure
    Community Member
    edited October 2022

    It seems like the issue is 1Password is using a kernel syscall instead of the dbus service and that kernel call is being blocked by a seccomp filter. I was able to get it to work by removing the filter from the ChromeOS side:

    1. Ctrl+Alt+t to open up crosh shell
    2. vmc start termina
    3. lxc stop penguin
    4. lxc profile unset default security.syscalls.blacklist
    5. lxc profile apply penguin default

    Then after rebooting the VM system authentication works.

    So I guess this is a feature request to support using libsecret or another alternative mechanism that works in unprivileged containers.

  • Hey @destructure, thanks for reaching out. I apologize for our delayed response.

    I'm glad to hear you were able to resolve the issue with a workaround! I'll pass these details along to our developers to see if this is something we can improve in a future update. Thanks!

This discussion has been closed.