GNOME Remote Desktop - RDP setup guide ($1778) · Snippets

Works like a charm from macOS 11.5.1 (Big Sur). This guide is a little hard to find though. Now I need to figure out how to run it headless.

Restart g-r-d via g-c-c at the end, so g-r-d starts the RDP server.

What does this mean, how to do that? I still only have a.out, is that "g-r-d" ? how to restart it?

@zilexa

I still only have a.out.

The a.out executable is just for setting the credentials.

What does this mean, how to do that? I still only have a.out, is that "g-r-d" ? how to restart it?

g-c-c is the abbreviation for gnome-control-center (also known as "GNOME Settings")
g-r-d is the abbreviation for gnome-remote-desktop. This is the actual server with the RDP backend here.

It means that you toggle the on/off button in gnome-control-center in the screen sharing settings to first turn screen sharing off (if it is not 'off' already) and then toggle the button again to turn it back on. This has the effect, that g-r-d (gnome-remote-desktop) is restarted.

Alternatively, you can use systemctl --user restart gnome-remote-desktop.service to restart g-r-d.

@pnowack Thanks so much for your swift response. I feel stupid now as this just refers to a simple UI toggle that I know well :)

Final question (hopefully). On Manjaro Gnome (fully updated, uses Gnome 40.4.0 with Wayland by default), org.gnome.desktop.remote-desktop.rdp does not exist. org.gnome.desktop.remote-access does exist, but does not contain tls-cert and tls-key. The remote-desktop schema is missing.

Is my Gnome version too old?

@zilexa

org.gnome.desktop.remote-access is not used by gnome-remote-desktop. It might be a leftover of the deprecated vino server.

org.gnome.desktop.remote-desktop.rdp should exist though (same as org.gnome.desktop.remote-desktop.vnc for the VNC backend). The key was introduced with g-r-d version 0.1.9 (that was the version before GNOME 40).
If it does not exist in your package, then the installation is faulty. If the problem persists with a reinstallation of the g-r-d package, then you should report that to your distribution.

gnome-remote-desktops latest versions (as of 2021-11-09 (YYYY-MM-DD)) are for GNOME-40: 40.2 and for GNOME 41: 41.1
You can check the version with /usr/lib/./gnome-remote-desktop-daemon --version (the path to the gnome-remote-desktop-daemon may vary from distro to distro).

@pnowack

Thanks, I was able to install the missing package easily and notified via the forum the dev team: https://forum.manjaro.org/t/missing-package-gnome-remote-desktop/89631

So far, when connecting from Windows, after entering credentials I see a small popup for 0.1sec, but nothing else happens. I am back at the Remote Desktop window where you can enter address.

If I keep trying, after 5 times or so Windows rdp says: "Because of a protocol error detected at the client (code 0x21040, this session will be disconnected". Probably because I tried too many times.

I will re-create the credentials just to be sure I did not make any mistakes. At least RDP is running:

● gnome-remote-desktop.service - GNOME Remote Desktop
     Loaded: loaded (/usr/lib/systemd/user/gnome-remote-desktop.service; static)
     Active: active (running) since Tue 2021-11-09 13:42:48 CET; 6min ago
   Main PID: 2291 (gnome-remote-de)
      Tasks: 4 (limit: 9086)
     Memory: 12.5M
        CPU: 390ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gnome-remote-desktop.service
             └─2291 /usr/lib/gnome-remote-desktop-daemon

nov 09 13:46:35 Idefix gnome-remote-desktop-daemon[2291]: [13:46:35:890] [2291:2378] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
nov 09 13:46:35 Idefix gnome-remote-de[2291]: Unable to check file descriptor, closing connection
nov 09 13:46:42 Idefix gnome-remote-desktop-daemon[2291]: [13:46:42:670] [2291:2387] [ERROR][com.freerdp.crypto] - invalid private key
nov 09 13:46:42 Idefix gnome-remote-desktop-daemon[2291]: [13:46:42:671] [2291:2387] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_INITIAL - rdp_server_accept_nego() fail
nov 09 13:46:42 Idefix gnome-remote-desktop-daemon[2291]: [13:46:42:671] [2291:2387] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
nov 09 13:46:42 Idefix gnome-remote-de[2291]: Unable to check file descriptor, closing connection
nov 09 13:46:46 Idefix gnome-remote-desktop-daemon[2291]: [13:46:46:051] [2291:2396] [ERROR][com.freerdp.crypto] - invalid private key
nov 09 13:46:46 Idefix gnome-remote-desktop-daemon[2291]: [13:46:46:051] [2291:2396] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_INITIAL - rdp_server_accept_nego() fail
nov 09 13:46:46 Idefix gnome-remote-desktop-daemon[2291]: [13:46:46:051] [2291:2396] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
nov 09 13:46:46 Idefix gnome-remote-de[2291]: Unable to check file descriptor, closing connection

@zilexa

[ERROR][com.freerdp.crypto] - invalid private key

You did not create the private keyfile and server certificate. Just follow the steps in the snippet here.
The part at Now create the server certificate and private keyfile via: is not done.
Just follow the steps in the snippet above to create both files and save their locations in gsettings like it is mentioned in the snippet.

It is pretty much just copy-paste.

Actually I did do that. The first time and now 3 times in total.

Each time, I copied the 2 files to a folder I created /home/myusername/.config/remote-desktop and I set the path via gsettings the first time. I confirmed this via gsettings list-recursively org.gnome.desktop.remote-desktop.rdp

Not sure why it still gives me this error. But I'll check again tomorrow.

@pnowack It works! I had a typo in the gsettings set command, the path of my .key file contained an extra /.

UPDATED 11/JAN/2021 I have created a little bash script to easily create the credentials, prevents myself and others to make typos. I will also use this in my Manjaro post-installation script:

# Install the gnome RDP package
sudo pacman -S --noconfirm gnome-remote-desktop

# Ask user what login name/pw they want to use
echo "Please create credentials to allow access by others:"
read -p 'Remote Desktop access username: ' rdpuser
read -p 'Remote Desktop access password (only letters and/or numbers!): ' rdppw
echo "Your username/password will be $rdpuser/$rdppw."
read -p "A self-signed certificate is required and will be created. Hit [ENTER] to start and prepare to answer questions for the certificate." 

# Download the code snippet that generates RDP credentials
wget -O $HOME/Downloads/grd_rdp_credentials.c https://gitlab.gnome.org/-/snippets/1778/raw/master/grd_rdp_credentials.c
# Compile the file
gcc grd_rdp_credentials.c `pkg-config --libs --cflags libsecret-1`
# Use the program to store the credentials via libsecret
./a.out $rdpuser $rdppw

# Create the server certificate and private keyfile
openssl genrsa -out tls.key 4096
openssl req -new -key tls.key -out tls.csr
openssl x509 -req -days 730 -signkey tls.key -in tls.csr -out tls.crt

# Move the certificate and keyfile to a better location
mkdir $HOME/.config/remote-desktop
mv $HOME/Downloads/tls.key $HOME/.config/remote-desktop/tls.key
mv $HOME/Downloads/tls.crt $HOME/.config/remote-desktop/tls.crt

# Set the location of the two files
dconf write /org/gnome/desktop/remote-desktop/rdp/tls-key "'$HOME/.config/remote-desktop/tls.key'" 
dconf write /org/gnome/desktop/remote-desktop/rdp/tls-cert "'$HOME/.config/remote-desktop/tls.crt'"

# Cleanup
rm $HOME/Downloads/tls.csr
rm $HOME/Downloads/a.out
rm $HOME/Downloads/grd_rdp_credentials.c    

echo "RDP credentials configured. Note RDP is still disabled! You can enable/disable RDP easily via Settings > Sharing > Share Screen."

@saaditory In your case it seems that the header files for libsecret are split into another package in your distribution (not the usual case).
So, in your case, your distro should have a -dev or -devel package for libsecret. I.e. could be named libsecret-dev, libsecret-devel, or similar.
So, in order to build the script, you need that package installed.

gcc grd_rdp_credentials.c `pkg-config --libs --cflags libsecret-1` While executing this, I'm getting the following error..

Package libsecret-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libsecret-1.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libsecret-1', required by 'virtual:world', not found
grd_rdp_credentials.c:3:10: fatal error: libsecret/secret.h: No such file or directory
    3 | #include <libsecret/secret.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

I don't know how to resolve it.

@pnowack Thanks, libsecret-devel package did the trick. I'm using Fedora 35.

The problem is that it is still not working... I may be missing something.. I ran the above script by @zilexa successfully, after that, I toggled the settings in GNOME Settings and even rebooted the PC but when I try to connect through Remmina, it says: Connot connect to the "192.168.x.x" RDP server.

Tried as well: sudo systemctl restart gnome-remote-desktop

@saaditory g-r-d is currently only a systemd user service, not a system service. This means that systemctl restart gnome-remote-desktop.service will not work, but systemctl --user restart gnome-remote-desktop.service will work (the --user switch is relevant)

(In case you want a headless session, this type of session is not implemented yet (tracking issues: https://gitlab.gnome.org/GNOME/mutter/-/issues/1605, https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/16))

Oh right, I get it. @pnowack Right now the output is:

● gnome-remote-desktop.service - GNOME Remote Desktop
     Loaded: loaded (/usr/lib/systemd/user/gnome-remote-desktop.service; static)
     Active: active (running) since Tue 2021-11-16 20:19:48 PKT; 9s ago
   Main PID: 10296 (gnome-remote-de)
      Tasks: 5 (limit: 9329)
     Memory: 2.8M
        CPU: 30ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gnome-remote-desktop.service
             └─10296 /usr/libexec/gnome-remote-desktop-daemon

Nov 16 20:19:48 elitebook-saad systemd[1606]: Starting GNOME Remote Desktop...
Nov 16 20:19:48 elitebook-saad systemd[1606]: Started GNOME Remote Desktop.
Nov 16 20:19:48 elitebook-saad gnome-remote-de[10296]: Didn't initialize RDP server: not configured
Nov 16 20:19:48 elitebook-saad gnome-remote-de[10296]: Initialized VNC server

Seems like it's not configured yet, but I ran the above script without any errors.

In case you want a headless session, this type of session is not implemented yet

@pnowack I'm trying to set it up on my laptop. Which definitely has everything like display etc. connected to it. Also I am logged in to this PC as well when trying to connect to it (if that's not something that I'm doing wrong).

@saaditory

If you have troubles, please do not rely on my script but follow the steps as described. That should work. I noticed for example the script does not solve the env variable HOME. This means your gsettings now contain invalid paths to "HOME" instead of /home/yourusersname/... but there might be more things going wrong as I only tested the script (with full paths instead of $HOME) on Manjaro Gnome latest version (that worked).

@zilexa You are right. gsettings commands are not resolving $HOME to be the actual user directory path. Changing them manually in my case resolved the issue.

But now I have some issue while connecting to the server. The connection fails on authentication and the RDP server stops. I'll try to look into more details on this one when I get time.

Thanks both @pnowack & @zilexa

Using these instructions I have rdp working on debian 11 with Gnome 41. The performance is great however the keyboard isn't being forwarded to the server. Mouse works fine. I have tried thinclient and remmina.

Any ideas?

@dubstar-04

debian 11 with Gnome 41

That does not add up. Debian 11 does not ship GNOME 41. It uses the old GNOME 3.38 version (, where g-r-ds version was 0.1.9).
Check your g-r-d version via apt or via running /usr/libexec/./gnome-remote-desktop-daemon --version. It MUST be >= 40.

Thanks for the quick response. I added testing to the sources list to get the newer packages. I only did this to try and get the keyboard working.

Needed to dist-upgrade to upgrade gnome-remote-desktop.

Working perfectly now.

Thank you.

Is it possible to show gdm3 when using gnome-remote-desktop?

@dubstar-04

Is it possible to show gdm3 when using gnome-remote-desktop?

It is not, headless sessions are not implemented yet.

Anyone know if it's possible to remotely start a gnome-session via ssh?

RDP works great once the session is logged in.

I have two seats on one machine. The second seat is headless using a dummy HDMI adapter and it's proving rather tricky to get logged in.

Best I have come up with us use no machine to log in then use the RDP built in to gnome/mutter.

@dubstar-04

Anyone know if it's possible to remotely start a gnome-session via ssh?

While I have not tested this, there might be a way: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/64#note_1104016

It should be noted though that, as the comment suggests, that this won't launch a full GNOME session.

No need for compiling anything to set username & pass

secret-tool store -l 'GNOME Remote Desktop RDP credentials' xdg:schema org.gnome.RemoteDesktop.RdpCredentials

When prompted for secret use this format:

{'username': <'admin'>, 'password': <'guessme'>}

@pnowack I created a repository on GitHub to develop a script for setting up the Gnome Remote Desktop server with a virtual monitor/display. The idea is to use (if possible) only command line utilities. However, I currently do have time to finish implementing it. If you or anyone is interested, feel free to send a PR or to use the code for another implementation. I was having issues with the gdbus calls in gnome-add-virtual-monitor.sh, by the way.

@tamirdaniely -- regarding your comment:

No need for compiling anything to set username & pass
secret-tool store -l 'GNOME Remote Desktop RDP credentials' xdg:schema org.gnome.RemoteDesktop.RdpCredentials

Thank you! I've just added this to the repo for replacing the compiled code.

@pnowack perhaps you can update the setup guide with the info from @tamirdaniely ?

No need for compiling anything to set username & pass

@tamirdaniely Your solution does not work. I have no RDP working after doing that, even though I enabled/disabled/enabled it via Settings>Sharing>Screen Sharing. Also, when I check tls-cert and tls-key in org.gnome.desktop.remote-desktop.rdp they are empty.

I have updated my 1-click script that will do all the steps of the guide automatically (and interactively ask for user/pw).

@saaditory I fixed the commands that set the location of the key files, I discovered you can use dconf instead of gsettings. Dconf does support $HOME.

With the UI freeze exception in https://gitlab.gnome.org/Teams/Releng/freeze-breaks/-/issues/56 and the respecting g-c-c MR in https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1205, GNOME 42 will provide a UI for the RDP backend.
With the new UI, the certificate and private keyfile are automatically created. If you configure or have already configured your own certificate and private keyfile, those remain preserved.

The RDP backend also becomes the default remote desktop backend. The VNC backend will, so far, still exist (just not be exposed to the UI any more).
Additionally, with GNOME 42, a CLI tool called grdctl is introduced, allowing you to configure both the RDP backend and VNC backend from the terminal too.

@pnowack I can't seem to find any documentation on the actual grdctl commands. help, -h and --h all do not give me any helpful output, and there is no man entry.

@CorvetteCole The help can be displayed with grdctl --help. Regarding the man page: It is currently an open MR: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/90

Note: Enabled and Disabled of the backends settings refer to the dconf settings. Enabled means that the backend (RDP or VNC) is started, when g-r-d is started.
Enabling the g-r-d systemd user service itself automatically is done via e.g. systemctl --user enable --now gnome-remote-desktop-daemon

@pnowack I apologize. Guess I didn't try all the help permutations! Appreciate the advice

I just discovered this step only works if your password contains letters and/or numbers. You cannot use "!" in your password, because this command will fail: ./a.out some_username p455w0rd!

Perhaps add this info in the guide?

My script still works btw: https://gitlab.gnome.org/-/snippets/1778#note_1310610

Since Gnome 42 is not available in stable Manjaro and I noticed there are still quite some issues with 42.1, most people might still be on 41.5. So this page is still very useful 😄

how to know if my nvidia gpu support the hardware acceleration？ and how to support hardware acceleration for amd gpu？

This is pretty rough. On Ubuntu 22.04, the secret-tool command fails with secret-tool: Cannot create an item in a locked collection, which is the same error message that grdctl rdp set-credentials was failing with.

This led me to the following hack: https://unix.stackexchange.com/a/602935/14020.

Once the credentials are 'set', the Windows RDP client exits with An internal error has occurred. and the server side logs show the following

Jul 31 17:13:54 optiplex gnome-remote-de[15480]: Couldn't retrieve RDP username: The name :1.29 was not provided by any .service files
Jul 31 17:13:54 optiplex gnome-remote-de[15480]: 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: Credentials not set
Jul 31 17:13:54 optiplex gnome-remote-de[15480]: Couldn't retrieve RDP username: The name :1.29 was not provided by any .service files

@voltagex You killed the keyring daemon, which is necessary for the authentication and you wonder why the authentication does not perform.
The keyring daemon must be running and unlocked, otherwise the connecting client cannot be authenticated.

The GError part here is unrelated, nothing serious, just double setting the error. It is fixed in g-r-d-43.

@voltagex Did you get any further? I'm still having credential issues in 22.04 as well.

@pnowack Is there any information we can get you to help improve this experience? Seems like there's something still very wrong with all this. (Broken in Ubuntu 22.04.1 LTS / GNOME Remote Desktop 42.3 out of the box.)

@WithinRafael emailed you, as this is probably not the right place to discuss this particular (and a couple of subsequent) issues.

Short version: Ubuntu needs to pull in upstream fixes from FreeRDP, gnome-remote-desktop needs to provide a way to unlock keychains without X11/Wayland running/active.

Following an update I am unable to access remote desktop. I tried accessing two different machines from 3 other machines and they all give an error:

I think both machines are using Gnome 42.3.

Any ideas?

Any ideas?

@dubstar-04 Well, if you are that thrifty with providing information, then nothing can be said. The error message is very generic, it doesn't indicate anything. I guess your client is here mstsc.

What was the last version that worked (i.e. without that message)?
What was the version to which you updated, where it starts showing that message?
Which distro (do you still use Debian here, like above)?
Do you use the proprietary NVIDIA drivers on that system (and is your GPU NVENC capable)?
What are your reproduction steps? I don't think I can reproduce it, but I need to roughly know what is going on.
What is the screen resolution on the server side?
Please attach any journal logs regarding g-r-d here (as file).

Edit: The version information (1. and 2.) is the most important part here.

I think both machine are using Gnome 42.3.

And the previous version, that worked? The diff between g-r-d-42.2 and g-r-d-42.3 does not have any protocol related changes, only crash and leak fixes.

Apologies for the sparse information.

I just checked the journal logs as you suggested and I see this:

Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:675] [13634:15435] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] Aug 16 16:41:36 popapad gnome-remote-de[13634]: Unable to check file descriptor, closing connection Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:710] [13634:15429] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312] Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:715] [13634:15429] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313] Aug 16 16:41:36 popapad gnome-remote-de[13634]: Downgrading colour depth from 24 to 16 due to issues with the interleaved codec Aug 16 16:41:36 popapad gnome-remote-de[13634]: [RDP.RDPGFX] CapsAdvertise: Accepting capability set with version RDPGFX_CAPVERSION_106, Client cap flags: H264 (AVC444): true, H264 (AVC420): true Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:295] [13634:15429] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:296] [13634:15429] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] Aug 16 16:41:36 popapad gnome-remote-de[13634]: Unable to check file descriptor, closing connection Aug 16 16:41:36 popapad gnome-remote-desktop-daemon[13634]: [16:41:36:317] [13634:13634] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe

Does that help any? I will reply with the remaining information shortly.

Comments below:

What was the last version that worked (i.e. without that message)? 42.2 I think.
What was the version to which you updated, where it starts showing that message? 43.3 is the first time I notice this.
Which distro (do you still use Debian here, like above)? yes Debian
Do you use the proprietary NVIDIA drivers on that system (and is your GPU NVENC capable)? Tried AMD-GPU RX570 and Intel UHD
What are your reproduction steps? I don't think I can reproduce it, but I need to roughly know what is going on. Enable RDP in settings and try to connect
What is the screen resolution on the server side? 1920x1080 & 1800x1200
Please attach any journal logs regarding g-r-d here (as file). See above. I can provide more if required

I have tried connecting from windows, Thincast Remote and Remmina.

Does that help any?

No, gnome-session is fully unrelated here.

**42.2 I think. **

Please (re)check this one. 42.2 is unlikely, as the changes there don't have a an effect on the RDP connection. I have a guess and that is 42.1.1. If that is the case, then g-r-d could have crashed here (check coredumpctl -r for a g-r-d crash). That crash should be fixed by https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/665f734ab7cdd52b9b2340e00f42f91a919baca7 (included in g-r-d-42.4).

Regarding the logs part, you can also run g-r-d manually with additional debug output via:

Since debug messages are suppressed by default, can you do the following:

Disable g-r-d (screen sharing toggle in GNOME Settings).
Open a terminal and run export G_MESSAGES_DEBUG=all to enable glib debug messages.
Run export WLOG_LEVEL=DEBUG to enable FreeRDP debug messages.
Run g-r-d directly from the terminal via /usr/libexec/./gnome-remote-desktop-daemon (Note: the path might be different on your distro. Usually, the gnome-remote-desktop-daemon is in /usr/lib/ or in /usr/libexec/).
Connect with your RDP client (every RDP client is different, while the message box in your screenshot above suggested the use of mstsc, always note which client was used).
Reproduce the error.
Copy the g-r-d output in the terminal into a file and attach the file here.

Any observations, when the message pops up can be helpful (e.g. were any frames visible, was a necessary operation necessary (e.g. copy pasting something, etc.)).

I updated the journal log. I pasted the wrong log, Sorry.

I updated the journal log

Ok, no indication from the logs. The client just disconnects. What is the log with Remmina or the Thincast client here?

This was with mstsc,

@dubstar-04 There is something that looked off to me in the logs, that you posted:

Downgrading colour depth from 24 to 16 due to issues with the interleaved codec
This message refers to the legacy path (and only affects the legacy path). The graphics pipeline (which is also correctly initialized in your case) is unaffected by this.
Anything in RDP with Windows 8 or later uses the graphics pipeline whenever possible (i.e. both peers support it), like also g-r-d since version 41. And anything in the graphics pipeline uses a colour depth of 32. It is how the protocol works.

So, I checked with mstsc in Win11, set the colour depth to 24 and was able to reproduce the message. It is though an error in mstsc, as anything in [MS-RDPEGFX] uses 32bit surfaces (and that DVC successfully initialized in your case (see the RDPGFX message, which is written, when the CapsAdvertise PDU was received)).

So, in mstsc go to the display settings and make sure 32bit it set as colour depth. It shouldn't be set to anything else. It's a setting for very old server (WinXP era) (same as the ancient "performance" settings (it should be set to "automatically detect")).
Both the 32bit colour depth setting and the network autodetect settings are though the standard settings, so you changed them before.

I have tried connecting from windows, Thincast Remote and Remmina.

Doubt that you tested the Thincast client here. (Remmina is linux-only btw).

I tried to follow the steps however I can't connect to gnome rdp. I retried using G-C-C and I saw this in the log.

Aug 16 17:24:57 popapad gnome-remote-desktop-daemon[16612]: [17:24:57:200] [16612:16846] [ERROR] com.freerdp.channels.rdpgfx.server] - WTSVirtualChannelRead failed! Aug 16 17:24:57 popapad gnome-remote-desktop-daemon[16612]: [17:24:57:201] [16612:16846] [ERROR][com.freerdp.channels.rdpgfx.server] - rdpgfx_server_handle_messages failed with error 1359 Aug 16 17:24:57 popapad gnome-remote-desktop-daemon[16612]: [17:24:57:201] [16612:16844] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 104: Connection reset by peer Aug 16 17:24:57 popapad gnome-remote-desktop-daemon[16612]: [17:24:57:201] [16612:16844] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]

Superb. That has fixed the issue with the windows connecting. I still can't connect from the linux clients. I will have another look at that now I know the server works.

I did try Thincast and Remmina...

Thank you for your help and support. Really appreciated.

I retried using G-C-C and I saw this in the log.

Just for information com.freerdp.channels.rdpgfx.server] - WTSVirtualChannelRead failed! in conjunction with ERRCONNECT_CONNECT_TRANSPORT_FAILED is harmless, as ERRCONNECT_CONNECT_TRANSPORT_FAILED always refers to a client disconnect.

I still can't connect from the linux clients.

Would be interested in the logs here.
Regarding Remmina: The version shouldn't be too old. Two years ago, I fixed some bugs, that prevented Remmina to work with g-r-d (https://gitlab.com/Remmina/Remmina/-/merge_requests/2099) and still some distros didn't update their pkgs (Ubuntu 20.04 for example). The Remmina version should be at least 1.4.8 (that already is very old).

Thank you for your help and support. Really appreciated.

Have to say though, that I can only say something, when I have some spare time left (and depending on the information that is given to me).

Hi Pascal,

I understand and I apologize for the lack of information. The issue was so easy for me to reproduce, I was certain it was a known problem.

Following up.

The issue with the Thincast remote client was the credentials. For some reason it wouldn't let me change the password. Updating to the latest flatpak shows a different ui with an entry for the user credentials and the Thincast client now works very well.

Thanks Again,

Dan

Thanks for the feedback.

Updating to the latest flatpak shows a different ui with an entry for the user credentials and the Thincast client now works very well.

Great to hear that!

I was certain it was a known problem.

The thought is common among users (leading to providing none or minimal information). Usually, its not known (or the issue description is very generic), which is why I was carpet bombing you with questions in https://gitlab.gnome.org/-/snippets/1778#note_1530286 with the intention to try to get a picture of the situation.

Does this work on RHEL 9? I had issues while trying with a machine that has an Nvidia graphics card with proprietary drivers installed.

$ /usr/libexec/./gnome-remote-desktop-daemon
(gnome-remote-desktop-daemon:84314): GLib-GIO-DEBUG: 11:35:37.626: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ?gsettings-backend?
(gnome-remote-desktop-daemon:84314): dconf-DEBUG: 11:35:37.626: watch_fast: "/org/gnome/desktop/remote-desktop/rdp/" (establishing: 0, active: 0)
(gnome-remote-desktop-daemon:84314): dconf-DEBUG: 11:35:37.626: watch_fast: "/org/gnome/desktop/remote-desktop/vnc/" (establishing: 0, active: 0)
(gnome-remote-desktop-daemon:84314): dconf-DEBUG: 11:35:37.628: watch_established: "/org/gnome/desktop/remote-desktop/rdp/" (establishing: 1)
(gnome-remote-desktop-daemon:84314): dconf-DEBUG: 11:35:37.628: watch_established: "/org/gnome/desktop/remote-desktop/vnc/" (establishing: 1)
** Message: 11:35:37.629: Initialized VNC server

I don't see any port 3389 open with the firewall disabled or under ss -tapn. Gnome v40 appears to be using Standard X11

@michaelbarkdoll

Gnome v40

That version is super ancient. Lots of changes and fixes went in g-r-d in the mean time (current supported version is 43). So, update your system first.
Note: g-r-d can be built with the RDP or VNC backend (unless explicitly mentioned 'or' is an implicit Or here).
So, check first whether g-r-d was properly built first (ask distro forum), i.e. which backends were enabled at build time.

I'm having no luck compiling grd_rdp_credentials.c.

I can only use CLI on SSH until I get RDP working and all I get is: grd_rdp_credentials.c:3:10: fatal error: libsecret/secret.h: No such file or directory 3 | #include <libsecret/secret.h>

The command I give is:

gcc grd_rdp_credentials.c pkg-config --libs --cflags libsecret-1-dev

The apt list shows: libsecret-1-dev/jammy 0.20.5-2 amd64

Wat am I doint wrong?

Do you need to compile anything? Have you tried turning on remote desktop in gnome settings?

I am stuck. I try: grdctl rdp set-credentials and nothing happens. The terminal just waits for more input.

I try with rdp enabled and rdp disabled. No difference. grdctl status gives: RDP: Status: enabled TLS certificate: /home/tbb06/.local/share/gnome-remote-desktop/rdp-tls.crt TLS key: /home/tbb06/.local/share/gnome-remote-desktop/rdp-tls.key View-only: no Username: (empty) Password: (empty)

@tbbrightman

grdctl rdp set-credentials and nothing happens. The terminal just waits for more input.

The username and pw need to be both provided to the cmdline. See also grdctl --help or man grdctl.

I can only use CLI on SSH until I get RDP working

Uhm, do you have a headless setup here? As written on the wiki page, g-r-d currently only has remote assistance sessions implemented. Headless sessions are not implemented yet. That is also mentioned in the comments above here.

This is NOT a headless setup. The desktop is XFCE4 desktop with Gnome 42.

XFCE4 does NOT support the gnome settings app. It does run gnome-control-center from the CLI but that doesn't provide rdp authentication.

Hence, I'm trying to launch rdp using ssh. My problem is that no matter what I try, grdctl rdp set-credentials does nothing. I try: grdctl rdp set-credentials and grdctl rdp set-credentials . Nothing. Ending with ^Z does no good.

I feel like a fool.

The desktop is XFCE4 desktop with Gnome 42.

How exactly does it look like? Do you use xfwm or gnome-shell? g-r-d is part of the GNOME desktop. Anything else is an unsupported setup. It requires mutter to be used (what gnome-shell (g-s) does).

My problem is that no matter what I try, grdctl rdp set-credentials does nothing.

The GNOME keyring needs to be unlocked. It should be set up by your distro already. gdm unlocks the keyring, as soon as you login by default (after you typed your password in the login screen and pressed the Return key).

I seem to be in way over my head. This is the result of ps -ax command: tbb06@VTDT2:~$ ps -ax | grep dm 839 ? S 8:48 /opt/remoteit/resources/linux/connectd -l 44397 80:00:00:00:01:24:A0:41 -s -e bWF4X2RlcHRoIDM1CmFwcGxpY2F0aW9uX3R5cGUgNDIKcHJveHlfZGVzdF9pcCAxMjcuMC4wLjEKbWFudWZhY3R1cmVfaWQgMzMwMjQKcGxhdGZvcm1fdmVyc2lvbiAxMTIwCnByb3h5X2Rlc3RfcG9ydCAyOTk5OQpVSUQgODA6MDA6MDA6MDA6MDE6MjQ6QTA6NDEKc2VjcmV0IEY1OUUzRjFERkJBMkNBQkY0NDNEQTUxRjFDQ0UzM0NFQ0UwOUYzNUEKIwo= 851 ? S 8:54 /opt/remoteit/resources/linux/connectd -l 41891 80:00:00:00:01:24:A0:B3 -s -e bWF4X2RlcHRoIDM1CmFwcGxpY2F0aW9uX3R5cGUgMjgKcHJveHlfZGVzdF9pcCAxMjcuMC4wLjEKbWFudWZhY3R1cmVfaWQgMzMwMjQKcGxhdGZvcm1fdmVyc2lvbiAxMTIwCnByb3h5X2Rlc3RfcG9ydCAyMgpVSUQgODA6MDA6MDA6MDA6MDE6MjQ6QTA6QjMKc2VjcmV0IDEwRDg3RTgzNDE1MUE0QzNBOEU1QUFGQzM4QjI0QjE1RkVBOURDNTQKIwo= 882 ? S 8:43 /opt/remoteit/resources/linux/connectd -l 51509 80:00:00:00:01:23:FC:C7 -s -e bWF4X2RlcHRoIDM1CmFwcGxpY2F0aW9uX3R5cGUgMzQKcHJveHlfZGVzdF9pcCAxMjcuMC4wLjEKbWFudWZhY3R1cmVfaWQgMzMwMjQKcGxhdGZvcm1fdmVyc2lvbiAxMTIwCnByb3h5X2Rlc3RfcG9ydCA0NDUKVUlEIDgwOjAwOjAwOjAwOjAxOjIzOkZDOkM3CnNlY3JldCBGMzU5REVEMDRGOTVCMDM2NzYxQTBCNjg0RDZFNDI0Mzg1OEU3MUIyCiMK 895 ? S 8:45 /opt/remoteit/resources/linux/connectd -l 34767 80:00:00:00:01:23:FC:C6 -s -e bWF4X2RlcHRoIDM1CmFwcGxpY2F0aW9uX3R5cGUgMzUKcHJveHlfZGVzdF9pcCAxMjcuMC4wLjEKbWFudWZhY3R1cmVfaWQgMzMwMjQKcGxhdGZvcm1fdmVyc2lvbiAxMTIwCnByb3h5X2Rlc3RfcG9ydCA2NTUzNQphcHBsaWNhdGlvbl90eXBlX292ZXJsb2FkIDQwClVJRCA4MDowMDowMDowMDowMToyMzpGQzpDNgpzZWNyZXQgNDFCRkE5ODMyOEE2M0RFNEY4MzgxRDA1OEExM0ZENjdGMzkzM0NFNgojCg== 1020 ? Ssl 0:00 /usr/sbin/gdm3 1089 ? Sl 0:00 gdm-session-worker [pam/gdm-autologin] 1154 tty2 Ssl+ 0:00 /usr/libexec/gdm-wayland-session env GNOME_SHELL_SESSION_MODE=ubuntu /usr/bin/gnome-session --session=ubuntu 1667357 pts/2 S+ 0:00 grep --color=auto dm

It reports that a Gnome-session is active. But I am logged in with Xrdp & SSH.