Access issue with SSDM-Greeter file
Access issue with SSDM-Greeter file
I adjusted the desktop theme in MX Linux KDE without installing any unofficial updates. Now I encounter this error before logging in. I accessed the affected area, but it’s locked and shows a lock icon. I suspect I need to modify the access permissions or something similar. The permission settings are currently grayed out. This issue also appeared on another PC using the same version of MX Linux 25 KDE.
Consider executing the command to adjust ownership, then restart the system to test. It seems the .config file might have incorrect access rights. All contents in /var/lib/sddm should belong to sddm, but they appear misconfigured.
I fixed it. I discovered this command while searching online, but I found it in Manjaro and other forums and wasn’t confident enough to just type a random command. Will this issue return if I make further changes in SDDM? Is there a permanent solution or a way to secure the necessary permissions? Also, I own a Debian 13 KDE PC. I’m not sure which setting I altered before, but I know I did the same and my PC doesn’t have the same problem. On all my Linux systems, only I use one user account and Wayland is active. I also recall changing DPI settings, including applying the same values for the login screen in SDDM. However, the login screen still shows 100%. So everything seems minor. I have a workaround that helped me on my Debian 13 PC, where I adjusted the DPI scaling. I was told it might be a KDE bug, but I hoped that would be resolved.
This command updates file permissions and ownership for a directory. It uses the chown utility to change the owner of the specified path, making it the user 'sddm' and group 'sddm'. The -R flag applies the change recursively to all files and subdirectories. If you're running as root, ensure the folder is properly owned before proceeding.
I didn't intend for Nayr438 to issue a random command. I thought it appeared on forums or Reddit about other distros, which made it seem spontaneous. However, I believe this relates to KDE, so it should work across all KDE distributions (and likely the latest ones). I realized a lot of Linux behavior depends on the specific distro, version, or age. Ownership changes permanently, so I won't need to repeat the steps even if I try again later. I have a cheat sheet for handling new installations, which should prevent the same error from occurring after a fresh setup.
run0 is systemd's adaptation of sudo through polkit and a sandbox, not a suid binary. This shouldn't occur. It also happens on Arch, where the initial config change is applied via systemsettings assigned to root rather than sddm. The issue lies with sddm still defaulting to X11, which doesn't support fractional scaling. To switch to Wayland, refer to the guide at https://wiki.archlinux.org/title/SDDM#KDE_Plasma_/_KWin (2.12.1). This will update your desktop settings, including display resolution and scaling, using SDDM. System Settings -> Login Screen (SDDM) -> Apply Plasma Settings.
You wouldn't be making a new file, but instead adding a configuration file that replaces existing settings. This approach lets you update the main config without losing your previous changes. The extension should be .conf, and a number at the start helps organize updates. You can apply several changes across different files as long as they affect distinct values, and if issues arise, remove the problematic file. The directory for drop-ins is /etc/sddm.conf.d/. You can switch to Wayland or use your preferred scaling method. If you switch to Wayland, make sure layer-shell-qt is installed and run the necessary commands to restart sddm.
I understand. You’d set up a text file named “Then enter this.” Your current method has drawbacks because moving the PC or adjusting scaling requires manual file changes. This isn’t a major problem since you rarely switch computers. The Arch Wiki info could help automate it, but I’m curious why this isn’t included in the distribution. Personally, I learned the hard way—doing less often is better.
Since it's a trial, I try it and it functions well, though experimentation means things might shift or fail. KDE doesn't manage its own Display Manager; sddm stands alone, which causes it to lag behind KDE updates. I think Fedora sets sddm to Wayland by default. Updated December 25, 2025 by Nayr438 — please mention fedora.