SUMMARY Note! I don't know if this is the right project or component. I have *no* idea about what part of KDE causes this bug. Unfortunately I don't see any "I have no idea" option. Feel free to move it. When using the experimental systemd KDE startup (see https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot), I discovered that changes are not applied from /etc/groups when I log out and back in again. Stopping the user session (systemctl stop user@1000.service as root) does make the change apply. Also, when not using systemd startup this works as expected. STEPS TO REPRODUCE 1. Log in from login manager 2. Add a new group (e.g. optical) to your user that you don't currently have (verify this first via the groups command) from a terminal using for example: sudo gpasswd -a youruser optical 3. Log out 4. Log back in 5. Check groups again in terminal. OBSERVED RESULT The newly added group is not applied. EXPECTED RESULT The newly added group should be applied. This is the case when NOT using systemdboot setting. It is also how other DEs (such as Cinnamon) work, and all other DEs and WMs I have used historically have worked. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 ADDITIONAL INFORMATION * I use lightdm 1.30.0 as the login manager. I don't know if this is different with sddm. * X11, not wayland
To confirm, you are logging out and logging back in again rather than rebooting, right? If so, does rebooting instead work? If that works, then I strongly suspect that this is fixed in Plasma 5.25 with https://invent.kde.org/plasma/plasma-workspace/-/commit/e1b146551a0623a308f09a2d9be417b9cf7a4e83. Can you upgrade to 5.25 and see if that fixes it for your log out+log in scenario?
I don't think that would affect it. The issue is: systemd --user starts and becomes a session leader systemd --user forks into plasmashell/whatever you change groups you log out and back in systemd --user forks into plasmashell/whatever but it's from the same instance so has the same permissions running newgrp should fix it?
> To confirm, you are logging out and logging back in again rather than rebooting, right? Indeed. > If so, does rebooting instead work? Not tested, but if systemctl stop user@1000.service works, I would assume that a reboot also would work. Do you think it is worth testing reboot specifically (I'd have to reenable systemdBoot etc to test this). > Can you upgrade to 5.25 and see if that fixes it for your log out+log in scenario? 5.25 is still in testing in Arch. I'll look into it as soon as it is stabilised. I really don't want to switch to testing. > but it's from the same instance so has the same permissions So why does this work properly in Cinnamon that to the best of my knowledge use systemd for the user session, just like Gnome? I haven't tested Gnome itself though (it has been a long time since I used it and I have no wish to install modern Gnome if I can at all avoid it). > running newgrp should fix it? Yes, but that works even if you don't log out and back in again. However, that starts a nested shell (you could exec newgrp, but it would still only affect that tab in your terminal emulator).
(In reply to Nate Graham from comment #1) > Can you upgrade to 5.25 and see if that fixes it for your log out+log in > scenario? I updated to 5.25.0. That did not fix the issue. Perhaps David Edmundson is correct.
Yeah, he usually is. :)
I don't think there's much we can do our end.
(In reply to David Edmundson from comment #6) > I don't think there's much we can do our end. If so, you would expect that gnome has the same issue? I can certainly install it and test it. Also, shouldn't this at least be added to known caveats at https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot ?