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.

    6 months later

    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".

          7 months later

          Thanks a lot, rest it works !
          gsettings reset org.gnome.desktop.lockdown disable-lock-screen

          a month later

          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!

            4 months later

            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.

              JoshStrobl First of all thanks for your time on this.

              I was not aware the screen saver is forked, but in the meantime I've pursued another avenue. I installed a fresh VM with Solus, updated to Gnome 3.38, configured the screensaver there to 1 minute and waited: the VM locks the screen properly.

              So now I'm wondering if the problem is that some configuration is broken in my system due to eopkg's failed rollback.

              When I tried to rollback from 3.38 with eopkg history -t n, that failed due to a missing package (vino is removed from the repo). So eopkg aborted the rollback mid-way and I was forced to re-install all updates to go back to latest. (NOTE: I tried to roll back due to the resolution bug which I had just run into, and my first reaction was to revert).

              I'm thinking that maybe some configuration was broken by eopkg when it interrupted its rollback?

              One last thing I investigated was this:

              I ran dbus-monitor in the VM and my desktop. I see in the VM these dbus messages when I go idle, the screen saver activates and when I move the mouse after:

              # idle detected
signal time=1607120427.055833 sender=:1.34 -> destination=:1.7 serial=149 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
method call time=1607120427.056460 sender=:1.7 -> destination=:1.34 serial=293 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch

# screen saver activated
signal time=1607120437.280720 sender=:1.11 -> destination=(null destination) serial=17 path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=ActiveChanged
method call time=1607120437.281013 sender=:1.24 -> destination=:1.34 serial=57 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddIdleWatch

# moved mouse, idle stop
method call time=1607120437.281120 sender=:1.24 -> destination=:1.34 serial=58 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch
signal time=1607120437.281972 sender=:1.34 -> destination=:1.24 serial=159 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired

              On the host which has the issue I see no mention of org.gnome.ScreenSaver. It simply doesn't activate:

              # idle detected
signal time=1607120702.020979 sender=:1.35 -> destination=:1.7 serial=367 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
method call time=1607120702.021405 sender=:1.7 -> destination=:1.35 serial=364 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch

# moved mouse, idle stop
signal time=1607120722.263449 sender=:1.35 -> destination=:1.7 serial=370 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired

              However, in the window running gnome-screensaver --debug I do see it noticing the inactivity:

              [watcher_idle_notice_cb] gs-monitor.c:126 (22:25:02):	 Idle notice signal detected: 1
[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:207 (22:25:02):	 Idle notice signal not handled: 1

              I wonder who is supposed to handle this signal being emitted by gs-watcher. It is very likely that this failure to handle this signal is the culprit. Does something receive it and fail to process it? Does the thing supposed to receive it not run on my box anymore causing this? I don't know much about GNOME/dbus architecture unfortunately so I don't know what's supposed to happen there.

                Finally fixed this!

                After compiling the forked budgie-screensaver and getting the same behavior, realizing the problem is on the receiving side of that signal (which I had no idea which application would be to follow through on that) I broke my desperation threshold: I reinstalled Solus (home is in a separate partition) yet the problem still persisted!

                Gutting as this was, I obviously knew at this point that it's something in my configuration (so .config folder). I made a backup of that config folder (and a mental note to myself to add the step of creating a new user and testing with that before reinstalling the OS) and then proceeded to rename it and log in again: BOOM screensaver works but a ton of customization missing!

                So now I was trying to find what exactly in .config affects this. I restored and renamed subdirs and very quickly narrowed this down to the "dconf" folder.

                I learned that this file can be dumped to text mode and ran dconf dump / > dconf.txt and reviewed it. I located 3 keys related to power management settings:

                [org/gnome/desktop/screensaver]
color-shading-type='solid'
idle-activation-enabled=false
lock-delay=uint32 30
lock-enabled=true
picture-options='zoom'
picture-uri='file:///usr/share/backgrounds/solus/SolusFresh.png'
primary-color='#000000'
secondary-color='#000000'
 

[org/gnome/desktop/session]
idle-delay=uint32 60
 
[org/gnome/settings-daemon/plugins/power]
idle-dim=true
power-button-action='interactive'
sleep-inactive-ac-timeout=3600
sleep-inactive-ac-type='nothing'
sleep-inactive-battery-timeout=1800
sleep-inactive-battery-type='nothing'

                The only thing suspect was idle-activation-enabled but nothing I did in the setting gui would flip it. Also, the above gsettings reset org.gnome.desktop.lockdown disable-lock-screen had not helped in my case (tried it again anyway). I ended up changing it manually with dconf write /org/gnome/desktop/screensaver/idle-activation-enabled true which worked, but that did not help either (no screensaver).

                So I just went nuclear again: logged out from X and logged into console, killed the dbus daemon process so that it is not running and reset all 3 categories with:

                dconf reset -f /org/gnome/settings-daemon/plugins/power/
dconf reset -f /org/gnome/desktop/session/
dconf reset -f /org/gnome/desktop/screensaver/

                A fresh dump revealed that these were no longer present in the file.

                So, I logged back in, went to "Settings->Power->Blank Screen" turned it down from 5 to 1, waited a minute and ...BOOM !!! Screensaver on! Screen blank. Power saving starts! On moving mouse the system is locked and asking for the password...

                I wasted probably 10 hours on this and do not wish it on my worst enemy.

                The only positive is that I've learned a bit about gnome's architecture, read some gnome code, built the screensaver manually, etc... So at least I learned something...