SDDM Can't Write to a Config File on Boot

For a week or two now I’ve been getting Configuration file "/home/$ME/.config/sddm-greeterrc" not writable. when booting. Clicking OK lets it continue as normal where I can then select my session and log in, etc, but it’s annoying nonetheless.

I’ve something similar happen before. Back then it was var/lib/sddm/.config/sddm-greeterrc that wasn’t writable as root had taken ownership of /var/lib/sddm and its contents if I remember correctly. In this case /var/lib/sddm and its contents are all owned by sddm and I have verified that /var/lib/sddm/.config/sddm-greeterrc does exist and is writable.

I find it strange that it’s looking for a file that I thought lived elsewhere, but I’ve tried creating sddm-greeterrc in .config anyway; changing its owner to sddm and ensuring it has read and write permissions. The issue remains.

Does anyone know what might have caused this?
Many thanks.

can you try

chown -R sddm:sddm /var/lib/sddm/.config

Problem unfortunately persists. I’m pretty sure sddm already owned everything in /var/lib/sddm anyway, but it was worth a shot.

Package sddm does not have any files under the /var tree.
Looks like sddm does special operations into /var/lib/sddm. The package itself contains nothing for the /var tree.

Are you using some additional greeter?

No, it’s the same as it’s always been.

Here sddm works without issues. So there probably is something different on your system. Can you share the journal about a failed sddm in boot?
If you can use TTY right after the failure, the command would be
After logging in use a terminal command

sudo journalctl -b -0 | eos-sendlog

and show the returned address here.

sudo journalctl -b -0 | eos-sendlog returns completely blank.

Edit: I didn’t have wgetpaste-eos installed but running sudo journalctl -b -0 | eos-sendlog -v still just gives

==> failed

warning: sending data to failed with code  3.
==> wgetpaste: failed

warning: sending data to wgetpaste failed with code  1.
==> OK

What does sddm-greeterrc file contain? I’ve checked on all of my KDE systems, including my EOS one, and that file does not exist on any of them.

In /home/me/.config, it doesn’t exist.
In /var/lib/sddm/.config it’s a 0 byte empy file.

I have an rpi4 also running EOS with Plasma (it doesn’t have the problem) and interestingly, I cannot even cd into /var/lib/sddm/.config/ without being su on that. I’m not sure if that’s normal or not.
Either way, sddm-greeterrc doens’t exist on that device.

I’ll try deleting it and see what happens.

I can’t find any reference to that file - no man pages, no config settings, nothing - except for errors reports exactly like yours. And this is going back 5+ years.

I just tried deleting it and nothing changed.
I’ve seen similar errors across many forums while researching this but they all seem to have the file in /var/lib/sddm/.config.
It’s especially strange that mine is looking for it in the home directory’s .config instead for some reason.
My random guess is that it’s some sort of flag file for something, but I don’t know why it would be in /var/lib/.config, much less the home directory.

/var/lib/sddm actually makes the most sense: it’s the home directory of the sddm user. I still don’t understand why there’s no docs on this file, or how/why it’s even created.

Obviously, it’s the time you decided to install sddm-git.
At least, that’s what my :crystal_ball: says.

Local files are usually used with Wayland.
sddm-git was supposed to run in Wayland, when normal sddm does not.

Blame my ball if this is false.

In any case, sync packages properly and post info and logs. :person_shrugging:

I’m using the standard sddm package at version (as expected) 0.19.0.
Which log files + info do you need?

BTW, eos-sendlog should work again. The pastebin site it used is not working anymore, so it is now changed.


Returned address is

This looks like a bug, maybe at sddm-greeter. Unless you modified ítsia behavior.
Sddm behaves like a normal user, but íts should be able to write in íts own home, but not in real user’s.

I would suggest checking and posting upstream (sddm).

Solved it.
I had XDG_CONFIG_HOME defined in /etc/environment, which had been fine for ages so I’m still not sure what changed, but defining it in a file in ~/.config/environment.d/ instead solves the problem.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.