keyring isn't being unlocked at login, so apps can't access stored credentials and create new keyrings instead #3331
Replies: 5 comments 11 replies
-
1 app after reboot always tries to make a new default keyring. Also 1Password needs 2-f authentification everytime for r/w.
|
Beta Was this translation helpful? Give feedback.
-
|
Did following to resolve:
The inconsistency most likely occured after update 3.1.0, if the keyrings have been tackled with. Didn't look further into it, but probably has something to do with the default keyring created using some manager like Seahorse, or the one created upon request by apps, that collided with the one created during install and unlocked by SDDM |
Beta Was this translation helpful? Give feedback.
-
|
I had a similar issue, apps always tried to create a new keyring. The reason was a corrupt entry in default keyring (caused by a proton app "proton-vpn-gtk-app", "proton-pass" or "proton-mail"). I removed the keyring entry and apps and it worked again. |
Beta Was this translation helpful? Give feedback.
-
|
I think I have found a solution. Feel free to critique and offer improvements. It appears that unencrypted gnome-keyring uses ini file format. Some apps, Proton (VPN, Bridge) being notorious, store multi-line secrets. This renders keyring file unreadable by gnome-keyring. Vast majority of Linux users stick with encrypted keyring that unlocks with login password. Encrypted keyring format is not susceptible to the issue. Since Omarchy uses passwordless autologin we hit a corner case. Here's how to switch to encrypted keyring that automatically unlocks on autologin. This solves keyring file corruption issue. The LogicSince your entire root filesystem (including
Step 1: Create the Secret KeyfileWe will generate a strong, random password and save it to a file that only Root can read.
Step 2: Set GNOME Keyring to use this SecretYou need to update your keyring to use the content of that file as its password.
Step 3: Create the Unlock ScriptCreate and edit #!/bin/bash
# Define your user and UID (1000 is the most common)
TARGET_USER="your_username"
USER_UID=1000
SECRET_FILE="/etc/keyring_secret"
# 1. Read the password from the locked-down file
# Only root can run this script, and only root can read that file.
if [ -f "$SECRET_FILE" ]; then
PASS=$(cat "$SECRET_FILE")
else
echo "Keyring secret file not found!"
exit 1
fi
# 2. Inject into the user's keyring daemon
if [ -n "$PASS" ]; then
runuser -u "$TARGET_USER" -- env XDG_RUNTIME_DIR="/run/user/$USER_UID" \
sh -c "echo -n '$PASS' | gnome-keyring-daemon --unlock"
fiStep 3.1: Make script executablesudo chmod +x /usr/local/sbin/unlock-keyring-secure.shStep 4: Create and enable unlock service
[Unit]
Description=Unlock User Keyring via Root File
# Wait until the user session is theoretically ready
After=user-runtime-dir@1000.service
Requires=user-runtime-dir@1000.service
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/unlock-keyring-secure.sh
User=root
[Install]
WantedBy=multi-user.targetEnable it: sudo systemctl daemon-reload
sudo systemctl enable keyring-unlock-root.serviceYou may still be asked to unlock keyring at the next reboot. Copy password by running Profit! |
Beta Was this translation helpful? Give feedback.
-
|
I found a workaround for brave I documented on #4302 ( I will try what is commented here #3331 (comment) |
Beta Was this translation helpful? Give feedback.



Uh oh!
There was an error while loading. Please reload this page.
-
System details
Omarchy 3.1.7 ROG Zephyrus G16 GU605MZ_GU605MZ (1.0)
What's wrong?
Beta Was this translation helpful? Give feedback.
All reactions