RL8: usermod → sssd db warnings

I was going to add a group to myself… Wanted to be able to run minicom w/o sudo. But, I was met with a lot of sssd warnings.

$ stat /dev/ttyUSB0 | grep -i gid
Access: (0660/crw-rw----)  Uid: (    0/    root)   Gid: (   18/ dialout)

$ sudo usermod -aG dialout $USER
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.23], expected [0.24] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.23], expected [0.24] for domain implicit_files!
Higher version of database is expected!
In order to upgrade the database, you must run SSSD.
Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Could not open available domains

I did see a post here on the forum about the sssd warnings: "DB version is too old" warnings Not sure I saw a solution there.

Here are a few more commands, if they are to any help. :crossed_fingers:

$ sudo ll /var/lib/sss/db/
total 5,6M
-rw-------. 1 root root 1,6M 17 maj  2024 cache_implicit_files.ldb
-rw-------. 1 sssd sssd 1,3M 14 aug  2023 config.ldb
-rw-------. 1 root root 1,3M  3 jan  2023 sssd.ldb
-rw-------. 1 root root 1,6M 17 maj  2024 timestamps_implicit_files.ldb

$ systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Wed 2026-08-26 07:40:00 CEST; 3s ago
           ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
           └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

# restarting sssd didn't help

$ sudo ll /etc/sssd/
total 0
drwx--x--x. 2 sssd sssd 6 28 jul 08.28 conf.d
drwx--x--x. 2 root root 6 28 jul 08.28 pki

$ sudo ll -R /etc/sssd/
/etc/sssd/:
total 0
drwx--x--x. 2 sssd sssd 6 28 jul 08.28 conf.d
drwx--x--x. 2 root root 6 28 jul 08.28 pki

/etc/sssd/conf.d:
total 0

/etc/sssd/pki:
total 0

Those “ldb” files looks quite old. I guess they’re from my install. At least one of them are. I installed this system in Jan 3, 2023.

$ stat / | grep Birth
 Birth: 2023-01-03 10:41:56.436982000 +0100

And I’m not sure why the /etc/sssd folders say July 28. I’ve never been into them before - so, I guess an update bumped the dates …and maybe an update broke it and introduced the wanrings? Just a guess, of course.

Did see 1 solution here: Fix "DB version too old " · GitHub

Would that one work?

Note: Despite the warnings, the group was added - so I don’t know where that leaves all the warnings.

$ groups $USER
er… : er… lp wheel cdrom dialout video audio mock
                         ˇˇˇˇˇˇˇ

Well, that didn’t work. Also found another one about stopping/disabling the service and reinstall the sssd-common packet, starting it again, and reboot. Nope.

Since my Gnome keychain now didn’t open on login, and when searching for that, there were a couple of ones mentioning sssd.

So, I ended up removing it all instead: dnf remove sssd*

/* Marking this solved now. Maybe not a solution per se - more like getting rid of the problem, but I really can’t spend hours troubleshooting something I don’t use. */

Note:

The sssd does not start, because there is no config for it:

/etc/sssd/sssd.conf does not exist
No files in /etc/sssd/conf.d

That is the default. Likewise, nsswitch probably should not mention sssd.
The example below is from a el10 – might differ from el8.

# cat /etc/nsswitch.conf 
# Generated by authselect
# Do not modify this file manually, use authselect instead. Any user changes will be overwritten.
# You can stop authselect from managing your configuration by calling 'authselect opt-out'.
# See authselect(8) for more details.

# In order of likelihood of use to accelerate lookup.
passwd:     files systemd
shadow:     files systemd
group:      files [SUCCESS=merge] systemd
hosts:      files  dns myhostname
services:   files
netgroup:   files
automount:  files

aliases:    files
ethers:     files
gshadow:    files systemd
networks:   files dns
protocols:  files
publickey:  files
rpc:        files
# authselect list
- local  	 Local users only
- sssd   	 Enable SSSD for system authentication (also for local users only)
- winbind	 Enable winbind for system authentication

# authselect current
Profile ID: local
Enabled features:
- with-fingerprint

Yes. This https://access.redhat.com/errata/RHSA-2026:46990 security patch is from July 2026.

Thank you! :+1: I’ll def save that, in case I’ll start using it later.

Ok, so I guess that security update broke it then (ie. introduced the warnings for other programs).

Yes, I saw that now in the status output (must’ve missed it earlier): “ In order to upgrade the database, you must run SSSD” …and not just delete the db’s and think it’s fine.

…which makes sense, but also forces me to config/setup a service I don’t use - just to get rid of the warnings. I guess it has to be that way, but still, a bit annoying.
―――

Well, it seems to work fine (for) now. pam is opening my keychain again, and no warnings when I add a group.

I’ll keep your el10 example and use it as a start, if I get real use of sssd and need to set it up. :crossed_fingers: :+1:

I read this page on sssd (RHEL8), and it looks the same (examples/values) as the pages for RHEL10. I’ll save those pages to read later and see if it’s something I’d have use for.

sssd is basically a rewrite of winbind from Samba and you only need to run winbind if you are running in some type of domain, so sssd will be pretty much the same. If your RL8 computer is a standalone computer, then you shouldn’t need to run sssd.

Thx for the info. :+1: Not sure if I know Winbind, never been a Win user. Well, I had an old used Windows machine for testing some websites in, but that was like pre-2007. I think I used Samba once on my old Mac. I used mactalk, netatalk and later afp a little more, when needed.
  Yes, it’s a standalone computer. I have a few others computers and things in my network and I use a local “domain.lan” on all, but they’re all kindof their own thing - so, not much sharing going on there. A little Syncthing, sshfs and nfs maybe. I usually use ssh most of the time to manage and move files between them, &/or running them with a kbd and screen - and some of them have a webconsole (eg router, switch, printer, phone).

Samba does not run on Macs, so you probably didn’t use Samba, you were probably using Apples implementation of SMB. It sounds like you are running a loose version of a workgroup and you only need to run winbind if you want map Windows SIDs to Unix IDs in a domain. The same goes for sssd, if your users are stored in /etc/passwd and there is no domain (active directory, freeipa, ldap, etc) then you do not need sssd.

Thx! :+1: No, I don’t have any AD, freeipa, etc.