secret-tool: Could not connect: No such file or directory

[D3vil0p3r]

Windows Version

Microsoft Windows [Version 10.0.22621.1265]

WSL Version

1.1.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 5.15.90.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Fri Jan 27 02:56:13 UTC 2023

Distro Version

Arch Linux latest

Other Software

secret-tool
libsecret 0.20.5-2
gnome-keyring 1:42.1-2

Repro Steps

I'm using an Arch Linux custom environment where I installed gnome-keyring and libsecret for using secret-tool.

When I run secret-tool store --label='test' key value by CLI, I get:

Password: <my psw>
secret-tool: Could not connect: No such file or directory

Even if I run secret-tool lookup key value I get:

secret-tool: Could not connect: No such file or directory

When I connect to this machine by Remote Desktop Service, secret-tool works correctly. This issue occurs only when I use the Windows Command Line.

However, by command line the GUI applications work correctly, indeed if I run code, despite the CLI, it opens the Visual Code GUI correctly, so I'm not sure if the secret-tool issue could be related to the way Xorg talks with WSL in an Arch Linux environment.

My $HOME/.xinitrc file has the following content:

#!/usr/bin/env bash
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
        xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
        xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
        xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
        xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ]; then
        for f in /etc/X11/xinit/xinitrc.d/?*.sh; do
                [ -x "$f" ] && . "$f"
        done
        unset f
fi

# Workaround for GNOME apps starting slowly
# See: https://bbs.archlinux.org/viewtopic.php?id=224787
dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY

# Start the GNOME session
exec gnome-session

The value of the specified env variables above are:
DBUS_SESSION_BUS_ADDRESS: unix:path=/run/user/0/bus
DISPLAY: :0
XAUTHORITY: empty

Expected Behavior

secret-tool stores the secrets correctly.

Actual Behavior

When I run secret-tool store --label='test' key value by CLI, I get:

Password: <my psw>
secret-tool: Could not connect: No such file or directory

Even if I run secret-tool lookup key value I get:

secret-tool: Could not connect: No such file or directory

Diagnostic Logs

No response

[AlEscher]

I had the exact same issue, a colleague suggested a workaround that works for me:
After starting WSL, execute dbus-update-activation-environment --systemd DISPLAY.
Afterwards everything worked as expected for me.
This command has to be run everytime you restart WSL unfortunately, but for now it seems to be the only solution unless this gets fixed.
Hope this helps.

[Boojapho]

Had a similar problem with libsecret / gnome-keyring. secret-tool interacts with the same backend. I'm using it as my Git credential helper and was getting the following errors:

git pull
(process:1560): libsecret-CRITICAL **: 11:28:38.117: secret_value_get_text: assertion 'value' failed

(process:1560): libsecret-CRITICAL **: 11:28:38.117: secret_value_unref: assertion 'value != NULL' failed
Username for 'https://dev.com': user
Password for 'https://[email protected]':

** (process:1568): CRITICAL **: 11:28:55.013: store failed: Cannot create an item in a locked collection

After running dbus-update-activation-environment --systemd DISPLAY, it successfully prompted me for my password to unlock the keyring.

This used to work fine without passing the DISPLAY environmental variable to dbus.

[Boojapho]

To make this permanent, you can add Environment=DISPLAY=:0 to your dbus service configuration so you don't need to run the command every time. This assumes you aren't changing the default DISPLAY variable that WSL creates.

/usr/lib/systemd/user/dbus.service:

[Unit]
Description=D-Bus User Message Bus
Documentation=man:dbus-daemon(1)
Requires=dbus.socket

[Service]
Environment=DISPLAY=:0
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig