By admin account do you mean you're logging in as root or you mean an account with sudo priveledges?
'Lock' doesn't work, and other weird user problems.
I'm having the same problem. Super+L
and clicking on "Lock" don't do anything.
Locking via shell works however with:
dm-tool lock
but not with:
gnome-screensaver-command --lock
Justin Admin account with sudo privileges.
- Edited
@ All user affected: What desktop environment are you running?
Il use Budgie desktop.
- Edited
Works fine for me. Latest Solus Budgie.
It's interesting. All users here have an updated Budgie.
2 users have a lock that works.
The rest do not.
If we were all running WIN I would easily guess "software conflict", when apps regularly over-rode the settings of another app.
Does such a thing as software conflict exist in solus/linux I wonder?
- Edited
seagle gnome-screensaver-command --lock
does not work but dm-tool lock
work for me
By running gnome-screensaver
in debug mode like this:
pkill -f gnome-screensaver
/usr/bin/gnome-screensaver --no-daemon --debug &
I noticed this output in the shell when trying to lock
[listener_lock_cb] gs-monitor.c:209 (10:02:48): Locking disabled by the administrator
Which got me to check org.gnome.desktop.lockdown
via gsettings
$ gsettings get org.gnome.desktop.lockdown disable-lock-screen
true
This nees to be set to false
sudo gsettings set org.gnome.desktop.lockdown disable-lock-screen 'false'
Now locking the computer is working normally again for me.
Thanks a lot, it works !
- Edited
seagle Late reply, but you cracked the case Seagle! Although I had to solve the problem using a slightly different gsetting command - thought I'd post here in case anyone else encountered this foible.
By running the following command I confirmed that the value for Gnome's desktop lockdown setting was 'true' when it should be 'false'.
sudo gsettings set org.gnome.desktop.lockdown disable-lock-screen 'false'
I tried to set it to 'false' using the set command but no dice for some reason, so I used the reset command which did the trick.
gsettings reset org.gnome.desktop.lockdown disable-lock-screen
The GUI lock function now works! Though the behaviour of Solus's locking system does seem slightly weird - I wonder why after locking and switching users, getting back into your account requires logging in on the home screen, and then typing the same password into the still active lock screen... seems a bit redundant to me as you've already proved you have the right credentials on the home screen.
trenchanter the "reset" probably makes more sense anyway than manually setting it to "false".
Thanks a lot, rest it works !
gsettings reset org.gnome.desktop.lockdown disable-lock-screen
- Edited
Sorry for the late reply, but I was having the exact same issue after last Friday's software update. trenchanter your solution did the trick to solve the lock issue. Thanks!
- Edited
I am getting this behavior after the upgrade of gnome-settings-daemon from 3.36.1-47-1-x86_64 to 3.38.1-48-1-x86_64.
I have not disabled this:
$ gsettings get org.gnome.desktop.lockdown disable-lock-screen
false
Despite this, my screen never locks. I ran gnome-screen-saver from command line with debugging enabled, as you can see below, it detects me "toggling" screen locking on/off:
/usr/bin/gnome-screensaver --no-daemon --debug
[key_changed_cb] gs-prefs.c:325 (18:25:18): lock-enabled=0
[gs_manager_set_lock_enabled] gs-manager.c:162 (18:25:18): GSManager: lock-enabled=0
[key_changed_cb] gs-prefs.c:325 (18:25:20): lock-enabled=1
[gs_manager_set_lock_enabled] gs-manager.c:162 (18:25:20): GSManager: lock-enabled=1
When I set the screen lock to 5 minutes I get this logged, which seems to indicate that the inactivity was identified, but nothing happens (my screen does not lock):
[watcher_idle_notice_cb] gs-monitor.c:126 (18:41:03): Idle notice signal detected: 1
[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:207 (18:41:03): Idle notice signal not handled: 1
(gnome-screensaver:51636): GLib-CRITICAL **: 18:41:03.501: Source ID 36 was not found when attempting to remove it
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:03): obj_path=/org/freedesktop/login1/session/c1 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:03): obj_path=/org/freedesktop/login1/seat/seat0 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:03): obj_path=/org/freedesktop/login1/user/_1000 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:03): obj_path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
When I move the mouse after seeing this message (because my screen stays on) I see this logged indicating it has understood that there is activity:
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:34): obj_path=/org/freedesktop/login1/session/c1 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:34): obj_path=/org/freedesktop/login1/seat/seat0 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:34): obj_path=/org/freedesktop/login1/user/_1000 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
[listener_dbus_handle_system_message] gs-listener-dbus.c:851 (18:41:34): obj_path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties method=PropertiesChanged destination=(null)
Both dm-tool lock
and Super-L seem to work fine.
Looking at the code of gs-watcher-x11.c, it seems like some signal is emitted but not handled, as the result variable &res indicates?
karypid You should be referencing our fork: https://github.com/getsolus/budgie-screensaver