How to replace Gnome keyring with KeepassXC as secret service?

I don’t think you will find any simple way to do what you want on GNOME, if it’s even possible at all. The answer linked below is from an Ubuntu community but most of what is said there applies on any distro. (Ignore the rest of the answers there, they are many years old).

My guess is that the easiest solution is to use KDE or Xfce instead of GNOME…

1 Like

Makes my :smiling_face_with_three_hearts: my KDE even more and I didn’t think it was even possible…

So remove quiet and if you use plymouth disable it. You need to see what is going on.

If you use Grub to unlock your Boot and/or Root partition, you need to unlock it first. Otherwise the Grub menu will not be shown, since it is stored in the locked boot folder.

I tried to change the PAM GDM files (commented all lines with out) and it worked as expect. However I do not use Grub to unlock my LUKS devices and I do not use plymouth.

Okay, I tried it again. Turns out it’s almost impossible to enter the grub menu on Manjaro without a degree is you have LUKS enabled. I had to enter my LUKS password and then had to wait a few seconds until the volume was decrypted, then I had to immediately press Esc. One second earlier and it would have cancelled the decryption, one second later and it would have been too late.

I’d much rather have a shortcut other than Esc that wouldn’t throw me into rescue mode if pressed too early. I guess I’ll have to set GRUB_TIMEOUT_STYLE from hidden to menu in the grub config.

Anyway, after entering grub I was able to select a timeshift snapshot, but not the one I created right before making the pam.d changes because timeshift failed to run update-grub or whatever to add those snapshots to the menu. Very unfortunate that this doesn’t happen automatically. So I had to boot my live USB again to fix things.

I got stuck at [ OK ] Started Modem Manager. btw.

Then after removing plymouth, I got stuck at [ OK ] Started Thunderbolt system service.

No obvious errors.

My changes btw:

# before making changes:
$ grep -r "" /etc/pam.d/
/etc/pam.d/gdm-autologin:auth       optional          
/etc/pam.d/gdm-autologin:session    optional           auto_start
/etc/pam.d/gdm-fingerprint:auth       optional          
/etc/pam.d/gdm-fingerprint:session    optional           auto_start
/etc/pam.d/gdm-password:auth       optional          
/etc/pam.d/gdm-password:password   optional           use_authtok
/etc/pam.d/gdm-password:session    optional           auto_start
/etc/pam.d/gdm-smartcard:auth       optional          
/etc/pam.d/gdm-smartcard:session    optional           auto_start

# apply changes
$ sudo sed -i '/^/#/' /etc/pam.d/*

# after making changes
$ grep -r "" /etc/pam.d/
/etc/pam.d/gdm-autologin:#auth       optional          
/etc/pam.d/gdm-autologin:#session    optional           auto_start
/etc/pam.d/gdm-fingerprint:#auth       optional          
/etc/pam.d/gdm-fingerprint:#session    optional           auto_start
/etc/pam.d/gdm-password:#auth       optional          
/etc/pam.d/gdm-password:#password   optional           use_authtok
/etc/pam.d/gdm-password:#session    optional           auto_start
/etc/pam.d/gdm-smartcard:#auth       optional          
/etc/pam.d/gdm-smartcard:#session    optional           auto_start

Why is it so complicated or impossible to disable Gnome Keyring on Manjaro when it’s so easy on other distributions?

Seeing as I don’t use Gnome (don’t like playing in heaps of sh…erm yeah) I don’t know about Gnome keyring actually. But from what I’ve read is that it’s very close to, if not completely impossible. But these looks promising:

Anything else…



I should’ve checked earlier, but:

There is a section Secret Service, so that’s possibly it.

Edit #2:

According to this page:

How to Disable GNOME Keyring Arch Linux

This feature bothers a lot of people and is generally considered really annoying because it keeps nagging you for a password even though you have never set it up or asked it to store passwords for you.

On Arch Linux it is apparently possible to disable the GNOME keyring with the following instructions.

Copy these files to your autostart directory:

cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart

Set autostart to disabled for each of these:

vi gnome-keyring-gpg.desktop:




(Or something like that, anyway.)

You will need to make the boot process more verbose, check the other Kernel command line options you are using. Or boot up your system and check the journal messages for the last boot, this will not work if you restore form timeshift. You will need to fix your system via a live environment and the the journal form there (Hint: --directory= will be needed) or boot your normal system and use -b-1 for the last boot.

The problem the OK lines are that these are the last successful started services, it does not show which service failed. Also depending at which state it stops, you can still switch to a tty.

I just needed to do three things, disable the systemd user service for the keyring, comented out the pam entries for and removed /etc/xdg/autostart/gnome-keyring-secrets.desktop . I had no problem booting and no keyring service was running after login.
Did not seems to be that complicated.

Turns out you are right, I was indeed able to switch into a tty. From there I was able to find the errors:

$ journalctl -b -p 3
Aug 26 18:04:29 tvk-xps159575 gdm-autologin][665]: PAM bad jump in stack
Aug 26 18:05:38 tvk-xps159575 systemd[782]: gnome-keyring-daemon.socket: Socket service gnome-keyring-daemon.service not loaded, refusing.
Aug 26 18:05:38 tvk-xps159575 systemd[782]: Failed to listen on GNOME Keyring daemon.

I was not able to restore my pam.d backup from tty though because after deleting the current pam.d directory, sudo stopped working so that I couldn’t cp the backup into /etc. So I had to boot into the live USB again to fix it.

I really wonder how our systems differ. Maybe gnome keyring is somehow integrated into the whole LUKS thing?

Well that is an explanation. I would not use autologin. :wink:
The problem is the line in /etc/pam.d/gdm-autologin above the first with
The default action is to skip one line, which means to skip system-local-login. (Or something similar, I not that similar with the pam actions, or the error is because this is now the last one starting with auth)
Either way, remove the # from this line, since it is not the auto_start, or use the optional shorthand action just for a test.

Oh, I see, I’d like to use autostart though because I already have LUKS encryption and don’t want to enter a second password every time with every restart.

My /etc/pam.d/gdm-autologin looks like this:


auth       required          
auth       requisite         
auth       optional          
auth       required          
auth       [success=ok default=1]
auth       optional          

account    include                     system-local-login

password   required          

session    include                     system-local-login
session    optional           auto_start

I’m not sure which line you are referring to that I should uncomment or add optional to.

I would try this:


auth       required          
auth       requisite         
auth       optional          
auth       required          
auth       [success=ok default=1]
auth       optional          

account    include                     system-local-login

password   required          

session    include                     system-local-login
#session    optional           auto_start

No # in front of auth optional



auth       required          
auth       requisite         
auth       optional          
auth       required          
auth       optional          
#auth       [success=ok default=1]
#auth       optional          

account    include                     system-local-login

password   required          

session    include                     system-local-login
#session    optional           auto_start

Both lines with with a # and a little different line for

I’m not sure if the second will work.

With the first suggestion, the keyring now starts like so:

/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

with its parent being /usr/lib/systemd/systemd --user.

I don’t understand why because I masked the service:

$ systemctl --user status gnome-keyring-daemon.socket                                                                                                    
○ gnome-keyring-daemon.socket
     Loaded: masked (Reason: Unit gnome-keyring-daemon.socket is masked.)
     Active: inactive (dead)
$ systemctl --user status gnome-keyring-daemon.service                                                                                                 
○ gnome-keyring-daemon.service
     Loaded: masked (Reason: Unit gnome-keyring-daemon.service is masked.)
     Active: inactive (dead)

Also, I was asked for the keyring password as soon as Gnome was showing up.

I will try the second suggestion now.


With your second suggestion, I got the exact same results.

You don’t need to, it will be the same result.

Please see my short summary

Check the status command, it will now be in a different spot. You fixed two, but there are tree things you need to do. The suggestion to copy the desktop file to the Home autostart folder and edit it did not worked for me. I simply removed the desktop file in /etc/xdg/autostart/ .

I had deleted the filed from /etc/xdg/autostart as well.

The only error left is:

Aug 26 20:30:27 tvk-xps159575 systemd[688]: Failed to start Application launched by gnome-session-binary.

I’m not sure you can fix it. If a program starts that needs the Gnome-Keyring it will fail. Maybe, if you use your other secrets provider, it will go away on it self?

Just keep in mind that the file will be restored the next time gnome-keyring will be updated. You might want to add it to NoExtract in your pacman.conf.

The thing with KeypassXC is that you can only enable the secret service integration, if gnome keyring is not running. When I kill Gnome keyring forcefully, I can enable the KeepassXC secret service integration, but on the next reboot Gnome keyring will overrule it again.

You could always create a systemd timer un8it to run on login that disables it…

Just a thought…


More info:

Edit #2:

Also see:

Edit #3:

Yes, I know that isn’t a solution. It’s but a workaround. It’s also the only thing that I can think of.

So then again check the systemctl status command and tell use where the process is.

Here is the (relevant) output:

    State: running
    Units: 433 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 0 units
    Since: Sun 2023-08-27 19:44:57 CEST; 37s ago
  systemd: 253.8-1-manjaro
   CGroup: /
           │ └─1 /sbin/init splash
               │ ├─742 "gdm-session-worker [pam/gdm-autologin]"
               │ ├─774 /usr/lib/gdm-wayland-session /usr/bin/gnome-session
               │ └─779 /usr/lib/gnome-session-binary
                   │ ├─1100 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Now it is started by dbus. This means you startet a program that needs the keyring running. Is that immediately after your system reached the GUI or after you start programs. Do use Wifi with NM and saved the password only for your user? Which program do you use that needs the gnome-keyring? A browser for example? You can try to use dbus-monitor (without any parameter) but there is usually a lot, and you need to start it before the gnome-keyring process is started.

If you are not able to find the program that sends the dbus request, there are 3 files in /usr/share/dbus-1/services/ that will start the gnome-keyring process .

It happens before starting any applications and I’m not sure which application would want to start it. My Wifi passwords don’t appear to be managed by Gnome keyring.

Any ideas how I could achieve that? autostart would probably too late, right? I tried creating a systmd service that starts right after dbus.service:

Description=DBus Monitor Service

ExecStart=/usr/bin/dbus-monitor > /var/log/dbus-monitor.log 2>&1


But it failed:

× dbus-monitor.service - DBus Monitor Service
     Loaded: loaded (/etc/systemd/system/dbus-monitor.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sun 2023-08-27 22:06:35 CEST; 1min 24s ago
   Duration: 1ms
    Process: 678 ExecStart=/usr/bin/dbus-monitor > /var/log/dbus-monitor.log 2>&1 (code=exited, status=1/FAILURE)
   Main PID: 678 (code=exited, status=1/FAILURE)
        CPU: 2ms

Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Scheduled restart job, restart counter is at 5.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: Stopped DBus Monitor Service.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Start request repeated too quickly.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Failed with result 'exit-code'.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: Failed to start DBus Monitor Service.

(/var/log/dbus-monitor.log does not exist btw)