SUMMARY After login, a warning/msg box is shown: Something like "No write access to $HOME directory (/home/userName) Plasma can't be started" STEPS TO REPRODUCE 1. chmod 500 ~/ 2. Log out and log in. 3. OBSERVED RESULT The said msg box appears, but plasma started "normal" after closing the window EXPECTED RESULT ksmserver shouldn't need write access to ~/ (top directory) or at least not require the user to close the msg box before anything can be done. A notification would suffice. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Graphics Platform: Wayland ADDITIONAL INFORMATION My home directory(top level) is r-x------ The config, cache and data directories are rwx------ AFAIK Plasma ecosystem has implemented the base directory specification to read/write its cache/configuration and data files from/to the user defined locations (with fallback to ~/.cache ~/.config ~/.local/{state,share} if not defined). But ksmserver wants write access to ~/. After closing the mentioned msg box, plasma starts fine as far as I can tell. Am using it and filling this bug report now ... This implies, that write access is not really needed. I must admit, that 99% of users may not notice this as they wouldn't change manually the permissions of their $HOME and well, "who cares about the 1%". I know, you guys have plenty of other more important things to do and I can understand if you close the bug report. Nevertheless, I would appreciate if someone would care, even a workaround will do the job, just don't want ksmserver or any other part of my beloved desktop to stay in my way. =============================== Here is the log from systemd journal (removed user and host name): =============================== $ journalctl --user status ksmserver.service × plasma-ksmserver.service - KDE Session Management Server Loaded: loaded (/usr/lib/systemd/user/plasma-ksmserver.service; disabled; preset: enabled) Active: failed (Result: exit-code) since Thu 2022-12-22 18:13:20 CET; 4min 41s ago Process: 13065 ExecStart=/usr/bin/ksmserver (code=exited, status=255/EXCEPTION) Main PID: 13065 (code=exited, status=255/EXCEPTION) CPU: 206ms Dez 22 18:12:07 systemd[1278]: Starting KDE Session Management Server... Dez 22 18:12:08 ksmserver[13065]: The following installation problem was detected Dez 22 18:12:08 ksmserver[13065]: while trying to start Plasma: Dez 22 18:12:08 ksmserver[13065]: No write access to $HOME directory (/home/userNAME). Dez 22 18:12:08 ksmserver[13065]: Plasma is unable to start. Dez 22 18:13:20 systemd[1278]: plasma-ksmserver.service: Main process exited, code=exited, status=255/EXCEPTION Dez 22 18:13:20 systemd[1278]: plasma-ksmserver.service: Failed with result 'exit-code'. Dez 22 18:13:20 systemd[1278]: Failed to start KDE Session Management Server. ================================= Here the listing of my user directory (redacted): ================================= $ ls -lad ~ dr-x------ userNAME userNAME /home/userNAME/ $ ls -la ~ drwxr-x--- userNAME userNAME .cache/ drwxr-x--- userNAME userNAME .config/ drwxr-x--- userNAME userNAME .local/
Relevant code is at https://invent.kde.org/plasma/plasma-workspace/-/blob/master/ksmserver/main.cpp#L124 It's checked as a "sanity check", not because it's strictly necessary for operation There's also a KDE_HOME_READONLY environment variable to suppress the check
@Nicolas Fella: Thanks for taking time to reply! >It's checked as a "sanity check", not because it's strictly necessary for operation It really looked like something broken beyond repair, the shell was not loaded/visible, just a black screen and the error window. One needs to close it for the shell to appear. >There's also a KDE_HOME_READONLY environment variable to suppress the check I tested it and indeed, the error window didn't appear! Now, I don't know how to proceed here. For me, the "problem" is solved in the sense that I can use my PC without ksmserver "blocking" the log in. Please feel free to close the report as you see fits if no further steps required. Anyway, thank you.
Maybe KDE_HOME_READONLY should get set automatically when $HOME is missing write permissions?
(In reply to Nate Graham from comment #3) > Maybe KDE_HOME_READONLY should get set automatically when $HOME is missing > write permissions? That would defeat the purpose of the environment variable I think. As far as I can tell it's only used to suppress warnings about home not being writable
Hmm, well if $HOME not being writable is a valid state, why bother to even check for it?
Presumably to warn about accidental setup issues. It's somewhat hard to tell though since there is a good chance this code is older than me :)
Heh, yeah. If it's just supposed to be a warning, it probably shouldn't entirely prevent Plasma from launching, though. That seems quite overly harsh.
*** Bug 467120 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2748
Git commit a9a0807aeec1bc7a2d40e367c6bfe682597a5561 by Nate Graham. Committed on 15/03/2023 at 01:33. Pushed by ngraham into branch 'master'. ksmserver: help users with intentionally read-only homedirs self-satisfy As part of its sanity check, ksmserver doesn't start Plasma if `$HOME` is read-only unless `KDE_HOME_READONLY=1` is set in the environment. But this is never told to the user, so an advanced user or system administrator who has intentionally set up the system this way won't know what to do about it and will submit a bug report to KDE. To resolve this, inform such users about the relevant environment variable in the error message, without giving specific details about how to set it. Advanced users will already know how to do this and thus self-satisfy. FIXED-IN: 6.0 M +3 -1 ksmserver/main.cpp https://invent.kde.org/plasma/plasma-workspace/commit/a9a0807aeec1bc7a2d40e367c6bfe682597a5561