Description of problem: After setting a screen sharing password, rebooting makes it disappear. Version-Release number of selected component (if applicable): 0.1.7-5.fc33 0.1.8-3.fc32 (from https://bugzilla.redhat.com/show_bug.cgi?id=1844993) How reproducible: Always Steps to Reproduce: 1. Set a password in Sharing->Screen Sharing 2. Reboot 3. Go back to Settings->Screen Sharing and see that the password field is empty even though the option to use one is still selected. Actual results: My password is forgotten and I can't connect via VNC until I set it again. Expected results: I can connect to VNC without having to reset the password. Additional info: This is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1683674 but I can't reopen it. It still applies to me in Fedora 32, 33, and Rawhide.
I, too, am having this bug. It might be a slightly different scenario as I disabled encryption with: #gsettings set org.gnome.desktop.remote-desktop.vnc encryption "['none']" so that I can connect from non-Linux clients. Albeit I would say it is unlikely it had an impact. I am using Wayland but not sure what the original ticket is for. gnome-remote-desktop-0.1.9-2.fc33.x86_64 gnome-session-wayland-session-3.38.0-1.fc33.x86_64 Steps to reproduce: 1. #gsettings set org.gnome.desktop.remote-desktop.vnc encryption "['none']" (not sure if it makes a difference) 2. Set a password from Gnome Settings in the interface on the right top 3. Windows TightVNC connects fine, works fine 4. Log off, then reboot. Or reboot directly from terminal with #reboot 5. Try connecting again, password is rejected: "password check failed!" 6. Go into configuration in the interface again, the option for "let users enter a password" is selected but no characters are showing as dots (might be expected behaviour to hide password length) 7. Close that screen, then open again, 8. The option is now changed to "ask you for confirmation" instead of "enter this password"! My guess is: The password is not recorded: "gsettings list-keys org.gnome.desktop.remote-desktop.vnc" only lists: "view-only", "auth-method", "encryption" but not "password", It is only saved in memory and is lost after reboot, It is still recorded somewhere that "password" auth is enabled, but password is not found The option is then silently changed to "ask for confirmation" because password was not found. I was so excited to go back to Linux as a desktop OS after 10 years but the lack of proper remote access to Wayland really disappointed me. Is it possible to give this a bit of higher priority? I would also settle for a workaround whether it's an init script/systemd service or cron job. Thank you!
I have found this in the log for gnome-remote-desktop.service when attempting to connect and send the password via TigerVNC: Nov 06 09:00:01 localhost.localdomain gnome-remote-de[1464]: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Password not set Nov 06 09:00:01 localhost.localdomain gnome-remote-de[1464]: Couldn't retrieve VNC password: The name is not activatable
I found a workaround. It seems the keyring is still locked by the time the remote-desktop-daemon is started and hence the VNC server is unable to read the password. When I opened Seahorse, it was saying it's still locked. My GNOME is set up to log in automatically, if that makes a difference. I'm killing the currently running gnome-keyring-daemon, creating a new daemon as unlocked and then starting it. Then I restart the remote-desktop-daemon and voilà! Remote desktop password is accepted!!! Commands (executed as the user, not root): # killall gnome-keyring-daemon # echo -n "keyringpasswordNOTVNCPASSWORD" | gnome-keyring-daemon -l -d # gnome-keyring-daemon -s # systemctl --user restart gnome-remote-desktop This could be a generic issue with desktop auto login or the keyring unlock in general. The VNC server rejecting the password might be just a symptom rather than the actual bug.
gnome-remote-desktop does indeed require an unlocked gnome-keyring to function, as the VNC password is securely stored as part of it. To avoid weird errors about wrong passwords, maybe gnome-remote-desktop can learn how to check whether the keyring is locked or not, if password authentication is used, and not enable the server until it's unlocked.
Apparently, keyring is not unlocked automatically when auto login is enabled, hence all the stuff above. The password for VNC was a requirement since I could not set up password-less VNC, or enable VNC on login screen in gdm on Wayland. (I would be happy with that because I could limit the VNC connections to localhost and do an SSH tunnel.) Workarounds: 1- Unlock keyring above via ssh as in my previous reploy, before logging in via VNC. 2- Set the keyring to have no password on it (haven't tested, also potentially unwanted) 3- Allow password-less VNC (not sure if it's supported, at least not in Sharing Settings in Control Center) Or ideally it would have been: 1- Password-less option combined with "VNC to gdm login screen" instead of full desktop 2- Ability to make VNC listen on localhost only (not via firewall but via Sharing Settings) 3- Unlocking of keyring automatically for reading VNC password or using a separate keyring to store it So maybe this ticket could be used as a feature request for either of these.
Option 2 is https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/28
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. 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 '33'. 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 33 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.
The exact same issue is still present in Fedora 35. No need to provide more details, as it is the same behavior than in fedora 33. This has not been resolved for years already.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 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.