Trying to unlock Gnome in a remote ThinLinc session results in "Authentication error" and a never ending spinner. This is what the log has to say: JS ERROR: !!! Failed to open reauthentication channel JS ERROR: !!! message = '"GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._gdm_5fdisplay_5ferror.Code2: Error getting seat id from systemd: No such file or directory"' JS ERROR: !!! fileName = 'undefined' JS ERROR: !!! lineNumber = 'undefined' JS ERROR: !!! stack = 'undefined' JS ERROR: !!! Exception was: TypeError: this._userVerifier is undefined JS ERROR: !!! message = '"this._userVerifier is undefined"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/gdm/util.js"' JS ERROR: !!! lineNumber = '456' JS ERROR: !!! stack = '"(false)@/usr/share/gnome-shell/js/gdm/util.js:456 wrapper(false)@/usr/share/gjs-1.0/lang.js:213 ("Failed to open reauthentication channel",[object GObject_Boxed])@/usr/share/gnome-shell/js/gdm/util.js:250 wrapper("Failed to open reauthentication channel",[object GObject_Boxed])@/usr/share/gjs-1.0/lang.js:213 ([object GObject_Object],[object GObject_Object])@/usr/share/gnome-shell/js/gdm/util.js:266 wrapper([object GObject_Object],[object GObject_Object])@/usr/share/gjs-1.0/lang.js:213 "' Since this is a remote session, a lack of a seat is perfectly normal. Similar behaviour has been noticed on Fedora 18, but the log there is more unclear: JS ERROR: !!! Exception was: TypeError: Object 0x7fee89e73e18 is not a subclass of (null), it's a GLib_Error JS ERROR: !!! message = '"Object 0x7fee89e73e18 is not a subclass of (null), it's a GLib_Error"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/gdm/util.js"' JS ERROR: !!! lineNumber = '159' JS ERROR: !!! stack = '"([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gnome-shell/js/gdm/util.js:159 wrapper([object _private_Gdm_Client],[object _private_Gio_SimpleAsyncResult])@/usr/share/gjs-1.0/lang.js:204 "'
Also reported upstream: https://bugzilla.gnome.org/show_bug.cgi?id=699806
I have the same problem when upgraded to Fedora 19, which comes with gnome 3.8 with no fallback mode. So I've been using gnome-shell in vnc session too now, and once the screen is locked, unlock is impossible with the "authentication failed" error message.
Maybe this will help others in the mean time (it did me at least): you can turn off screen locking from the gnome setting to prevent this from happening, but if your screen is already locked and you have SSH access you can get rid of it by killing the "gnome-shell" process. (source: http://blog.mornati.net/2013/03/25/fedora-18-cant-unlock-the-screen/)
Upstream bugzilla says this is fixed now. (Looks like the fix hasn't made it into Fedora yet.)
*** Bug 1098740 has been marked as a duplicate of this bug. ***
The fixes landed upstream between 3.10 and 3.12, so indeed they are not in the GNOME versions in Fedora 19 and 20 (3.8 and 3.10 respectively). I've asked Ray on the upstream bug if it would be possible to backport them.
*** Bug 912892 has been marked as a duplicate of this bug. ***
According to https://bugzilla.redhat.com/show_bug.cgi?id=1112982#c22 I repost my bugreport regarding the unlock-issue when working with x0vncserver/vinagre here: I confirm the bug on a headless F20 installation. Access is done via x0vncserver and Vinagre, following http://www.janbambas.cz/headless-fedora-20-and-vnc-with-autologin Deleting all journallogs as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1002464#c17 doesn't help for me. This error occurs when usin a F20 upgraded from F19 via fedup as well as on a fresh installed F20.
Created attachment 920595 [details] journalctl -af For comment 8.
I also have this problem on my host and 5 VMs. Consistent behavior across all machines and users.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
As noted above, this is affecting Fedora 20 so can we get the version number in this report changed? (I can confirm it is fixed in Fedora 21, however.)
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening. Still broken.
Are you sure it's the same bug? It works well on my Fedora 26 here.
Same here on Fedora 26 system on an iMac, but logged in to remotely via SSH tunnel to a vncserver process on localhost. 1) Install tigervnc-server 2) Start vncserver 3) Connect to VNC session (tried MacOS "Screen Sharing.app" and also RealVNC Viewer) 4) Enter VNC password 5) Enter Gnome logon screen password 6) Leave VNC session inactive for a while so that the Gnome lock screen kicks in. 7) Return to VNC, Gnome lock screen appears, along with "Authentication error" below the "password" field. Also, one is unable to type in a password, after a few characters the field is reset and "Authentication error" is always (re)printed. === syslog messages start to appear with step 7: Oct 30 05:22:41 disko gnome-shell[31443]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Oct 30 05:22:42 disko gnome-shell[31443]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Oct 30 05:22:43 disko gnome-shell[31443]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available ShellUserVerifier<._reauthenticationChannelOpened@resource:///org/gnome/shell/gdm/util.js:353:34 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Oct 30 05:22:43 disko gnome-shell[31443]: JS ERROR: TypeError: childToShow is null AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:90:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Indicator<._updatePowerOff@resource:///org/gnome/shell/ui/status/system.js:337:62 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Indicator<._sessionUpdated@resource:///org/gnome/shell/ui/status/system.js:232:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 _emit@resource:///org/gnome/gjs/modules/signals.js:126:27 SessionMode<._sync@resource:///org/gnome/shell/ui/sessionMode.js:205:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 SessionMode<.popMode@resource:///org/gnome/shell/ui/sessionMode.js:174:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 ScreenShield<._hideLockScreenComplete@resource:///org/gnome/shell/ui/screenShield.js:922:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 _addHandler/params[name]@resource:///org/gnome/shell/ui/tweener.js:91:13 _callOnFunction@resource:///org/gnome/gjs/modules/tweener/tweener.js:203:13 _updateTweenByIndex@resource:///org/gnome/gjs/modules/tweener/tweener.js:332:1 _updateTweens@resource:///org/gnome/gjs/modules/tweener/tweener.js:345:18 _onEnterFrame@resource:///org/gnome/gjs/modules/tweener/tweener.js:360:10 _emit@resource:///org/gnome/gjs/modules/signals.js:126:27 ClutterFrameTicker<._onNewFrame@resource:///org/gnome/shell/ui/tweener.js:208:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 ClutterFrameTicker<._init/<@resource:///org/gnome/shell/ui/tweener.js:183:17
(In reply to Pierre Ossman from comment #17) > Are you sure it's the same bug? It works well on my Fedora 26 here. I'm seeing the problem with F26 and vncviewer, logging into a RHEL system. When the screensaver kicks in, unlocking does not work. Well, it does, but there is no keyboard. If I ssh to the machine running vncviewer I can kill the vncviewer process and all is well again.
The important part is the server, so if you're not seeing this with a Fedora server then I don't think it's the same bug and you should probably file a new one for RHEL. However Christian seems to be running a Fedora server, so that would mean the bug is back. How are you starting your VNC server, Christian? When I tried it I ran the 'vncserver' command after SSH:ing to the machine in question.
OK, the system I reported this about is a Fedora 26 desktop machine, located in some remote office, probably presenting a Gnome login screen right now. So what I did is login via SSH, install "tigervnc-server" and then as a user (still logged in via SSH) start "/bin/vncserver" w/o arguments. I could then login to the desktop with this VNC client on my Mac. Worked flawlessly for some time, but after the window was in the background for some minutes, the Gnome screen lock must've kicked in and when I returned the Gnome lock screen appeared. And then I could not login any more and syslog had the messages I pasted above. Searching for these messages online brought me to this bug and I assumed that I must have run in into this 4 year old bug. Happens a lot to me :-) After adding my comment here, I accepted my fate that I really won't be able to resurrect this session so I rebooted the machine and tried again. But this time it worked: the screen lock kicks in, but I can unlock the machine just fine. Tried different VNC viewers, doesn't matter, I'm now unable to reproduce this issue here. So I respectfuly want to retract my "me too" comment above, but I really thought I ran into this exact issue, especially since the syslog messages were awfully similar. Fun fact: even though VNC login/screen unlock works now, the messages in syslog are still being generated! When VNC connects to the screen and the screenlock appears: ============================== Oct 31 13:06:11 disko gnome-shell[2278]: JS ERROR: TypeError: childToShow is null AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:90:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 AltSwitcher<._onCapturedEvent@resource:///org/gnome/shell/ui/status/system.js:117:17 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Oct 31 13:06:11 disko gnome-shell[2278]: JS ERROR: TypeError: childToShow is null AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:90:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 AltSwitcher<._onCapturedEvent@resource:///org/gnome/shell/ui/status/system.js:117:17 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 ============================== And then, upon login: ============================== Oct 31 13:06:16 disko gnome-shell[2278]: JS ERROR: TypeError: childToShow is null AltSwitcher<._sync@resource:///org/gnome/shell/ui/status/system.js:90:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Indicator<._updatePowerOff@resource:///org/gnome/shell/ui/status/system.js:337:62 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 Indicator<._sessionUpdated@resource:///org/gnome/shell/ui/status/system.js:232:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 _emit@resource:///org/gnome/gjs/modules/signals.js:126:27 SessionMode<._sync@resource:///org/gnome/shell/ui/sessionMode.js:205:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 SessionMode<.popMode@resource:///org/gnome/shell/ui/sessionMode.js:174:9 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 ScreenShield<._hideLockScreenComplete@resource:///org/gnome/shell/ui/screenShield.js:922:13 wrapper@resource:///org/gnome/gjs/modules/lang.js:178:22 [....] ============================== ...but all that is material for a different bug report, I guess.
Same problem on FC 27 upgrade. I have to kill gnome-shell and I can get into the session... gnome-shell[19387]: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No session available
Bug or misconfig also present for me with rh7, gnome, tigervncserver but... unlocking a running session worked for me with: loginctl list-sessions loginctl unlock-session Cheers,
(In reply to bugshone from comment #23) > Bug or misconfig also present for me with rh7, gnome, tigervncserver but... > > unlocking a running session worked for me with: > > loginctl list-sessions > loginctl unlock-session > > Cheers, Thanks! Kind of an annoying extra step each day...
(In reply to Daniel Zirkin from comment #24) > (In reply to bugshone from comment #23) > > Bug or misconfig also present for me with rh7, gnome, tigervncserver but... > > > > unlocking a running session worked for me with: > > > > loginctl list-sessions > > loginctl unlock-session > > Just to note that this behavior / issue exists with CENTOS 7 The loginctl commands above works to unlock the session.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I have this problem on Fedora 27 currently with all updates applied. How do I keep this thread alive?
I have exactly the same problem in Fedora 28 with all updates.4.17.12-200.fc28.x86_64 #1 SMP Fri Aug 3 15:01:13 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux tigervnc-1.9.0-2.fc28.x86_64 tigervnc-server-1.9.0-2.fc28.x86_64 Any ideas?
loginctl unlock-session [session_num] doesn't work for me using ssh to call loginctl with tiger-vnc as the vnc server. I tried every session returned from list-sessions
The only thing I've been able to do successfully is keep restarting vnc on another screen through ssh, but then I have to reopen all the apps on the gnome desktop
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The problem still appears in Fedora rawhide and can still be resolved as described here. https://bugzilla.redhat.com/show_bug.cgi?id=912892#c10 Steps to Reproduce: 1. dnf install tigervnc-server 2. configure as per documentation 3. connect using tigervnc-viewer (vncviewer) 4. Lock Screen 5. Try to unlock screen Actual results: Unable to unlock screen Expected results: Be able to unlock and return to desktop Workaround: - Login with ssh - loginctl list-sessions - loginctl unlock-session $session