Bug: sbx login fails to save credentials on WSL in v0.31.0

[jns-br]

Description

sbx login completes the browser authentication flow successfully but then fails when attempting to save credentials, with the error:

ERROR: auth login failed: saving credentials: Object does not exist at path "/"

This is a regression — sbx login worked correctly on the same machine with v0.30.0.

Environment

• OS: Ubuntu 24.04 (Noble) running under WSL2 on Windows
• sbx version (broken): 0.31.0-1ubuntu.24.04noble
• sbx version (working): 0.30.0-1ubuntu.24.04noble
• Install method: curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh && sudo apt-get install docker-sbx

Steps to reproduce

1. Install docker-sbx v0.31.0 on WSL2 Ubuntu 24.04
2. Run sbx login
3. Complete the browser device auth flow (code displayed, URL opened, authentication succeeds)
4. Observe error when credentials are saved

Actual behavior

WARN: unknown authentication error type encountered: retrieve default account metadata: Object does not exist at path "/"
Your one-time device confirmation code is: XXXX-XXXX
Open this URL to sign in: https://login.docker.com/activate?user_code=XXXX-XXXX
Waiting for authentication...
ERROR: auth login failed: saving credentials: Object does not exist at path "/"

Expected behavior

Credentials are saved successfully after completing the auth flow, as they were in v0.30.0.

Workaround

Downgrading to v0.30.0 resolves the issue:

sudo apt-get install docker-sbx=0.30.0-1~ubuntu.24.04~noble
sudo apt-mark hold docker-sbx

Additional context

• ~/.docker/config.json has "credsStore": "" (explicitly cleared to rule out credential helper issues)
• ~/.sbx and ~/.config/com.docker.sandboxes/ were both deleted and recreated fresh — issue persists
• WSL2 does not have a D-Bus secret service / keyring daemon running, which may be related to the root cause if v0.31.0 changed how credentials are stored

[kiview]

WSL2 does not have a D-Bus secret service / keyring daemon running, which may be related to the root cause if v0.31.0 changed how credentials are stored

Given that you are using the Linux binary, that is likely the culprit, yes. Although the package has a dependency on it (but I guess the service does not start on WSL?).

[kiview]

We are considering using an encrypted file as a fallback mechanism on Linux without PAM.

[ram-fabian-heinrich]

Also experiencing this issue on a slightly different environment:

• OS: Ubuntu 26.04 LTS (Resolute Raccoon) running as a Hyper-V VM
• Kernel: 7.0.0-22-generic
• sbx version (broken): 0.31.0-1~ubuntu.26.04~resolute (also reproduced on 0.31.1)
• sbx version (working): 0.30.0-1~ubuntu.26.04~resolute (currently pinned)
• Docker version: 29.1.3

Same error as reported. Worth noting: gnome-keyring-daemon is running in my environment,

Downgrading to v0.30.0 resolves the issue.

[therw]

sbx v0.31.1-1 running in WSL Ubuntu 24.04 for a few weeks

This morning I've discovered another message :
sbx ERROR: unexpected authentication error: unexpected authentication failure: Object does not exist at path "/"

Tried sbx login and ended up with the error that started this thread

Switched back to 0.30.0-1 and it works for now

[boan-jfm]

Thank you, I just cleared all my configurations and couldn't figure out what was wrong. 😅

ERROR: unexpected authentication error: unexpected authentication failure: Object does not exist at path “/”