Hi,
I am a beginner (14+- days of use). this is my 2th attempt at the os, first time I used AI's help till it crashed everything.
In both attempts I have this problem: some app keeps asking for password whatever I do. when I open the root folder (not in terminal), when I use the internet, when I open other folders or files and so on. I can put in 5 mints my password more then 4 times. I am so sad and frustrated.
I have a password that I put when I enter the user and it's the same as the gnome-keyring's password. (so it sould have been fine). I also have keepass that connects to the browser (brave).
In my second attempt I tried to learn more from the internet the from AI. I searched 2 days and used AI to try find a salutation and I didn't.
I don't want to comprise my security by using a blank password. I tried many thing that the AI asked and probably hurt my os.
would appreciate help with the problem itself and with restoring any damage I might did 
for reference:
** 
a summary of all I'v done:**
Technical Summary: GNOME Keyring Debugging (Zorin OS)
1. Diagnostic Tests & Logs (What we checked)
- Process Verification:
- Command:
ps aux | grep gnome-keyring-daemon - Goal: To check if the service starts automatically with the session.
- Observation: The service was running, but sometimes in a "double" state (
discover_other_daemon: 1) or without the necessary components.
- Command:
- Environment Variables Check (The Decisive Test):
- Command:
echo $SSH_AUTH_SOCKandecho $GNOME_KEYRING_CONTROL - Your Results:
SSH_AUTH_SOCK: Returned a valid path (e.g.,/run/user/1000/keyring/ssh)
.GNOME_KEYRING_CONTROL: Returned Empty
.
- Conclusion: The desktop session was not connected to the secrets database, causing applications (Brave, Chrome, VS Code) to prompt for passwords repeatedly.
- Command:
- Keyring Content Analysis (Seahorse GUI):
- Observation: Only one keyring named "Login" existed , but all items had a lock icon
, indicating the keyring was not unlocking automatically upon login.
- Observation: Only one keyring named "Login" existed
2. Proposed Commands for Fixing & Resetting
- Resetting the Database (Deleting Corrupted Files):
rm -f ~/.local/share/keyrings/login.keyringrm -f ~/.local/share/keyrings/user.keystore- Or the broad reset/backup command:
rm ~/.local/share/keyrings/*ormv ~/.local/share/keyrings ~/.local/share/keyrings.backup.
- Manual Service Activation (For Testing):
Bashkillall gnome-keyring-daemon eval $(gnome-keyring-daemon --start --components=secrets,pkcs11,ssh) export GNOME_KEYRING_CONTROL GNOME_KEYRING_PID - Creating a Persistent Fix Script (Autostart): Creating a file at
~/.config/autostart/fix-keyring.desktopto execute:gnome-keyring-daemon --start --components=secrets,pkcs11,ssh && dbus-update-activation-environment --all
3. System Settings & Configuration Checks
- PAM Configuration (Login Authentication): Verified that
/etc/pam.d/gdm-passwordincludes:auth optional pam_gnome_keyring.sosession optional pam_gnome_keyring.so auto_start
- User Profile Configurations: Attempted to add the export commands to
~/.profileor~/.bashrc:Basheval $(gnome-keyring-daemon --start --components=secrets,pkcs11,ssh) export GNOME_KEYRING_CONTROL GNOME_KEYRING_PID - D-Bus Mechanism: Used the command
dbus-update-activation-environment --allto "push" the Keyring variables to the rest of the system environment.
4. Critical Insights & Safety Information
- The Auto-login Conflict: If Zorin OS is set to log in automatically without a password, the Keyring will never unlock on its own
. It requires the physical password entry to decrypt the database. - Missing Components: Running the daemon with only
--components=sshis insufficient for browsers; thesecretscomponent is mandatory. - Safety & Risks: Deleting the
keyringsfolder does not delete software or break the system
. It also does not delete Wi-Fi passwords (stored in NetworkManager), it only resets the GNOME password vault. - KeePass Compatibility: Since the primary passwords are managed in KeePass, resetting the GNOME Keyring is a safe and effective way to clear session-related "stuck" locks.
** 
a longer veirtuon of what I'v done:**
Step 1: Resetting the "Stuck" Database
Sometimes the Login file is simply corrupted and prevents the service from starting. This command deletes it (don't worry, the system will create a new and healthy one as soon as you type your password):
Bash
Bashrm -f ~/.local/share/keyrings/login.keyring rm -f ~/.local/share/keyrings/user.keystore
Step 2: Creating a "Fix Script" that will run every time the computer starts
Instead of getting complicated with graphical interfaces that don't always save changes, we will create a small file that will force the system to activate everything correctly.
Run the following command (copy the entire block and paste it into the terminal):
Bash
Bashcat <<EOF > ~/.config/autostart/fix-keyring.desktop [Desktop Entry] Type=Application Exec=sh -c "gnome-keyring-daemon --start --components=secrets,pkcs11,ssh && dbus-update-activation-environment --all" Hidden=false NoDisplay=false X-GNOME-Autostart-enabled=true Name=Fix Keyring Service EOF
What does this code do? It creates an "Autostart" file that tells the computer: "As soon as the user logs in, activate the Keyring with all the components and update the entire system (D-Bus) that it exists."
Step 3: Restarting the service (without restarting the computer)
To check if it works now, run these two commands one after the other:
Closing the stuck service:
Bash
Bashkillall gnome-keyring-daemon
(If it is not running, you will receive an error - that's fine).
Proper activation of the service:
Bash
Basheval $(gnome-keyring-daemon --start --components=secrets,pkcs11,ssh) export GNOME_KEYRING_CONTROL GNOME_KEYRING_PID
How will you know 100% that it is fixed?
Run this command in the terminal:
Bash
Bashecho $GNOME_KEYRING_CONTROL
If you received a path (something that looks like /run/user/1000/keyring...): Congratulations! Everything is fine. The system finally sees the database.
If the line is empty: The service is still failing to export its variables.
Your next step:
After running the commands, perform a Restart on the computer. When you enter, the system may ask you to "create a new password for the Keyring." Enter your regular user password. From now on, it will open everything automatically.
Step 1: Deleting the old Login file
Don't worry, it doesn't harm the system, it just makes it "forget" the lock that got stuck.
Open a terminal and run the following command:
Bash
Bashrm ~/.local/share/keyrings/login.keyring
(If the command says that the file does not exist, try running ls ~/.local/share/keyrings to see the exact name of the file there, maybe it's called Default.keyring).
Step 2: Re-establishing the connection
Perform a Restart on the computer.
After you have logged in (Login), open the browser or try to access the ROOT folder.
The system will pop up a window: "Create New Keyring" or "Choose password for new keyring."
This is the critical moment: Enter the password there that you use to log into the computer.
Confirm.
Why is this supposed to work?
Sometimes the Keyring file is "locked" on an old unique ID of the system (for example after an update or a change in the .profile settings we did earlier). When you delete the file and create it anew with the same password while you are already inside the system, the PAM (which we saw is configured correctly) succeeds in "injecting" the password smoothly from now on.
If even this didn't help (the last and sure resort):
If after the reset it still pops up, there is one setting in Zorin that causes this sometimes – Automatic Login.
Does the computer log into your user directly when you turn it on without asking for a password?
If so: The Keyring will never open automatically (because you didn't type a password). In such a case, the only solution is to cancel the Automatic Login in the user settings, or to leave a blank Keyring password (as I explained in the previous message).
Did you manage to delete the file and create a new one?
Analysis of External Resources
1. Arch Linux Forums (ID: 144783)
What was the problem the writer described?
The user succeeds in activating the Daemon, but the environment variables (like the one we searched for, GNOME_KEYRING_CONTROL) are not initialized, and therefore programs like SSH or browsers do not find the keys.
"The daemon is running, but the environment variables are not set. I can see the process with ps aux, but echo $GNOME_KEYRING_CONTROL returns nothing."
What did the most successful solution consist of and what does it do/say?
Using dbus-update-activation-environment. The solution consists of adding a command that updates the system's "bulletin board" (D-Bus) regarding the variables of the Keyring. This causes every application that opens from now on to know exactly where the Keyring is located.
"Add dbus-update-activation-environment --all or specifically for the keyring variables in your startup script."
2. LinuxQuestions (Slackware Bug)
What was the problem the writer described?
A specific bug in which the Keyring fails to initialize the secrets component (the database) because it tries to connect to a path that does not exist or that it does not have permissions for during the startup.
"The keyring daemon fails to initialize the secrets component properly during the X session startup, leading to manual password prompts later."
What did the most successful solution consist of and what does it do/say?
Separation of the activation components. Instead of activating everything at once, specific parameters are used (--components=secrets). The solution tells the system: "Don't try to guess what to activate, only activate the passwords and secrets component explicitly." This prevents conflicts with other components (like GPG) that might "catch" the process.
"Explicitly start the daemon with --components=secrets,pkcs11 and ensure the output is eval'd by the shell."
3. Launchpad (Ubuntu Bug #1407154)
What was the problem the writer described?
This is a famous bug in Ubuntu (on which Zorin is based). The problem is a "Race Condition": the Keyring tries to start before the user's D-Bus is ready, and therefore it does not succeed in registering in the system.
"Gnome-keyring-daemon starts too early or loses connection to the session bus, making it 'invisible' to the desktop environment."
What did the most successful solution consist of and what does it do/say?
Updating packages and changing the .desktop files in the Autostart folder (what we checked earlier). The solution consists of adding a slight delay or an assurance that the Daemon will be activated only after the graphics environment (X11/Wayland) is completely stable.
"The fix involved changing how the desktop files in /etc/xdg/autostart interact with the session manager to ensure environment variables are exported correctly."
4. Ubuntu Manpages (gnome-keyring-daemon.1)
What was the problem the writer described?
Here there is no "problem" but a technical explanation of the command, but the guide notes that it is mandatory to use eval so that the variables permeate into the system.
"The daemon will print env variables to stdout. To set these variables in your shell, you must use the eval command."
What did the most successful solution consist of and what does it do/say?
The use of the --start flag. The page explains that when running the Daemon with --start, it not only activates the service but also emits the addresses of the "pipes" (Sockets) through which the applications talk to it.
"Use gnome-keyring-daemon --start to initialize the daemon and environment. This is typically done by the session manager."
What does this mean for you?
All these sources point to the fact that the process with you is running, but it is "isolated." it did not succeed in telling the system "I am here."
Since the change in .profile caused the fault, the safest way in Zorin (without editing dangerous text files) is:
- Open the "Startup Applications" app.
- Search there for lines of GNOME Keyring.
- If they exist, click on "Edit" and make sure the command there includes the word
--start.
Would you like me to explain how to perform this action through the graphical interface so as not to risk the system startup again?
By the way, to enjoy all the features of the interfaces, you need to turn on the [Gemini Apps Activity] setting.
User said:
/usr/bin/gnome-keyring-daemon --start --components=ssh
Gemini said:
The command you wrote is exactly the "missing link" that causes your workspace to start communicating with the Keyring, but it has a small trap: it activates only the SSH component (keys for connecting to servers) and not the Secrets component (the passwords of the browser, Wi-Fi, and the applications).
Here is the analysis of what happens when running this command and how to use it correctly in Zorin to solve the problem without crashing:
What does this command do?
--start: Tells the Daemon "wake up and output your connection data."--components=ssh: Limits the Keyring to work only with SSH keys. This is the reason that if you run only it, the rest of your passwords (like in Chrome or VS Code) will still not be recognized.
How to use this to solve the problem (without risk):
Instead of adding this to system files (which we have already seen cause problems in Zorin), we will use the safe graphical interface:
- Open the menu and click on "Startup Applications."
- Search if an item named "GNOME Keyring Daemon" exists.
- Click on Edit and change the command line to this:
gnome-keyring-daemon --start --components=secrets,pkcs11,ssh
Explanation: We added secrets – this is the critical component that you are missing so that the browser and the system stop asking for a password.
Why is this the "correct" solution according to the sources you sent?
In the source from Arch Linux that you attached, it was noted that the problem is that the Daemon is running but the variables are not "exported." When running the command with --start and with the explicit components, the system forces the Desktop Session to "listen" to the Keyring.
Important Tip:
If after the restart you run in the terminal:
echo $GNOME_KEYRING_CONTROL
And you still receive an empty line, it's a sign that your workspace (Zorin Desktop) is blocking the export of this variable. In such a case, we will need to add one simple command in Startup Applications called:
dbus-update-activation-environment --all
This is the least invasive step – it does not touch the Boot files and cannot prevent the computer from starting, it simply "refreshes" the memory of the workspace as soon as it is already up.
Did you manage to find "GNOME Keyring" in the list of startup applications?
What is seen on your end:
You have:
- Only one keyring named Login (this is good)
- Inside it items like:
- Brave Safe Storage
- Chrome Safe Storage Control:backhand_index_pointing_right: These are not additional keyrings — these are simply items/tokens that applications save inside the keyring.
Meaning: You do not have a "multiple keyrings" problem.So my previous hypothesis was not correct in your case — let's move forward.
So what IS the problem?
What is seen in the photo:
Next to each item there is a lock → this means that the keyring is currently locked.
And this is the matter:
Even if it "opens sometimes," it probably locks again too quickly / does not open in the session as it should.
The right direction now (this is the key):
There is a very common situation where:
The keyring DOES open in the login.
But the environment (session) does not "remember" it.
And then every application asks again.
This happens when environment variables are not loaded correctly.
Critical check (this will decide):
Run in terminal:
echo $SSH_AUTH_SOCK
echo $GNOME_KEYRING_CONTROL
If one of them is empty / does not exist → we found the problem.
A solution that closes this in most cases:
- Do not manually run the:
gnome-keyring-daemon --start This is important — because it can create a double session (and we saw a hint of this: discover_other_daemon: 1). - Adding correct initialization:Open:
~/.bashrc(or.profile)And add at the end:
Bashif [ -n "$GNOME_KEYRING_CONTROL" ]; then export $(cat $GNOME_KEYRING_CONTROL) fi
Save, and then:
- logout
- login again
Why is this the solution?
Your problem is not:
Wrong password
PAM
Multiple keyrings
But rather:
session is not connected correctly to gnome-keyring.
Regarding KeePass:
You are working correctly 
KeePass is for personal password management.
And GNOME Keyring:
- Is used for the system (SSH, apps, tokens).
- Does not replace KeePass — but complements it.
If this still doesn't solve it:
There is one last direction (deeper with dbus / gnome-session), but let's check this first — because this solves ~90% of cases like yours.
If you feel like it — send me the output of the two echo commands and I will direct you accurately one more step
User said:
sapir@zorin-G5-KF5:~$ echo $SSH_AUTH_SOCK echo $GNOME_KEYRING_CONTROL /run/user/1000/keyring/ssh
Gemini said:
Excellent — this is exactly what was needed
And your output is very clear:
SSH_AUTH_SOCK is defined
But:
There is no value for GNOME_KEYRING_CONTROL 
This is the root of the problem:
You have a half-functional state:
SSH_AUTH_SOCK is defined
But GNOME_KEYRING_CONTROL is missing.
Meaning your session is not connected as it should be to GNOME Keyring.
And this is exactly why:
- Sometimes it works.
- But most of the time it asks for a password again and again.
The solution (accurate for your case):
Step 1 — cleaning a broken state:
First of all, let's delete the keyring to prevent conflicts:
rm ~/.local/share/keyrings/*
Step 2 — fixing the session:
Open: ~/.profile
And add at the end:
Basheval $(gnome-keyring-daemon --start --components=secrets,pkcs11,ssh) export GNOME_KEYRING_CONTROL GNOME_KEYRING_PID
Pay attention — we also added an export for GNOME_KEYRING_CONTROL (this was missing on your end!).
Step 3 — restarting:
- logout
- login
How will you know that it's fixed?
After login:
echo $GNOME_KEYRING_CONTROL
should return something like: /run/user/1000/keyring/control
And then:
There should be no more password requests all the time.
Very important:
Do not run manually anymore: gnome-keyring-daemon --start
This creates a double state (and we saw that this already happened on your end).
Short summary:
You don't have a password problem.
You don't have a keyrings problem.
You have an environment/session problem.
And now we solved it directly.
If after this it still happens — there is one more direction (related to DBus/gnome-session in Zorin OS), but let's see first that this is solved — because this is exactly your symptom.
User said:
rm ~/.local/share/keyrings/* - What exactly does this command do? Won't it risk my computer by deleting the software?
Gemini said:
An excellent question — and it's good that you stopped to check before you run it
What exactly does this command do?
It deletes all the files inside your keyrings folder.
It's important to understand:
It does not delete software.
It does not harm the system.
It does not risk the computer.
It DOES delete:
- Saved passwords inside GNOME Keyring.
- Tokens of applications (like browsers, Git, etc.).
What is the meaning in practice?
After the run:
- Your keyring "resets."
- The system will create a clean new one at the next entry.
- You will be asked to re-enter passwords for applications (like Brave/Chrome, etc.).
Why is this safe specifically in your case?
Because you wrote that you are using KeePass.
So:
- Your important passwords do not depend on GNOME Keyring at all.
- They will not be deleted and will not be harmed.
When is it NOT recommended to run this?
Only if:
- You have important passwords saved inside GNOME Keyring itself.
- And you don't know how to restore them.
Simple summary:
The command:
- Does not delete software.
- Does not break the system.
- Yes "resets" the password system of GNOME.
A gentler tip (if you are concerned):
It is possible instead of deleting — just to change the name (backup):
mv ~/.local/share/keyrings ~/.local/share/keyrings.backup
This will give you:
- The same effect.
- But with the option to restore if necessary.
If you want, we can also try a solution without deletion at all — but according to your symptoms, this is one of the cleanest and fastest solutions.
User said:
Does it not delete the Wi-Fi protection data and so on?
Gemini said:
An excellent question — and this is exactly the place to be precise
The short answer:
No — it will not delete your Wi-Fi passwords.
Why?
In Linux (including Zorin OS):
- Wi-Fi passwords are saved by
NetworkManager. - They are in files like:
/etc/NetworkManager/system-connections/. - And this is not related at all to GNOME Keyring.
So what IS deleted?
The command rm ~/.local/share/keyrings/* will delete only:
- Passwords of applications (browser, Git, etc.).
- Tokens (for example automatic login to sites).
- SSH keys if they were saved there.
A small exception (rare):
If you connected to Wi-Fi in a very specific way (for example with a private/enterprise password through keyring)
maybe you will be asked to enter a password again.
But:
The networks themselves will not be deleted.
You will not "lose" Wi-Fi.
Clear summary:
Does not delete Wi-Fi.
Does not harm network connections.
Yes resets passwords of applications.
If you want to be 100% calm — it is possible to go for the safe version (backup) that I wrote earlier, and then there is no risk at all
Gemini said:
If the user and the keyring passwords are already identical — then the problem is not with the password, but rather that GNOME Keyring does not open automatically through the authentication mechanism (PAM).
This is a relatively common situation in Zorin/Ubuntu when there is a fault in the settings.
Quick check (most important):
Run in terminal: ps aux | grep gnome-keyring-daemon
If you don't see a line with --start or --daemonize → it is not loaded automatically.
Solution 1 (The correct one): PAM fix
You need to make sure that the following file includes the keyring line:
Open: sudo nano /etc/pam.d/gdm-password
And look for a line like this:
auth optional pam_gnome_keyring.so
session optional pam_gnome_keyring.so auto_start
If it does not exist — add it.
This is what causes GNOME Keyring to open automatically with the login.
Solution 2 (Quick check without risk):
Manually run: gnome-keyring-daemon --start --components=secrets
If after this:
- There are no more password requests.→ this confirms that the problem is in the automatic activation.
Solution 3 (A very common case!):
If you enter with Auto-login (login automatically without typing a password)
then the keyring will not open by itself — because there is no authentication event.
Solution:
- Disable Auto-login.
- Or define a keyring without a password (less secure).
Solution 4 (Full restart of keyring):
Sometimes simply: rm -rf ~/.local/share/keyrings/*
And then reconnecting — solves.
Focused summary:
If the passwords are identical and it still asks:
- Check if the service is running at all.
- If not — it's a PAM problem.
- Check if Auto-login is active.
- If necessary — reset keyring.
If you want, send me:
- How you enter (with password / automatic).
- Output of the
pscommand.And I will direct you exactly to the right solution for you.
