tonynupe

Hi there, I no longer have this issue on the newer version but I'm using RDP via IP address.

Hello

Thanks @tonynupe for sharing the results, unfortunately it doesn't give me any clue.

Here's where I'm at with this: when we initialize FreeRDP, we need to provide it a path to store files. When FreeRDP bootstraps TLS (needed for basically 99% of RDP servers), it evaluates the path we gave it and if it's not valid for some reason, the connection gets terminated very early. It's only checking that the path "looks" like a valid path, not that it actually exists or is writeable etc.

in RDM Linux we had some changes here that exposed a problem: we're asking .NET for the path to the user's documents directory and handing it to FreeRDP. On Linux, that path is calculated based on the current environment. In FlatPak deployments, .NET was not able to resolve that path (I think that's actually a bug on the .NET side or at least a mis-documentation on their part), so we ended up handing on empty string to FreeRDP, which rejected that (sensibly) as an invalid path, which meant TLS could not be bootstrapped.

This issue has identical symptoms, but I cannot logically explain it as the same thing. Because on macOS, .NET asks the OS where the documents path is (it's not calculated from the user environment) and I can't find any reasonable scenario where that path would be empty or invalid. Actually I can think of a few, but the output of the script I asked you to run shows that, at least in the general case, this is working properly on your side.

However I have to assume that this is all related in a way that I don't see right now, as we have identical symptoms and this is one of the only code paths that can affect this. This thread is the only 2 reports I've had of this problem which implies something unexpected in your respective environments.

What I've done is modify the code in RDM Mac to always fallback to a valid path, even if the system gives us something unexpected. The resolved value is also logged. I think these changes should fix the issue and if they don't, they'll provide enough information to troubleshoot further. Unfortunately there won't be any more 2025.3 builds, but 2026.1 is due to be released on March 2nd and will contain these changes.

In the meantime please stay with 2025.3.9.2 and once 2026.1 is released, this should either be fixed or we'll have more information to take it further. I am sorry for the inconvenience and thank you for your patience

Kind regards,

@Richard Markiewicz

Good day Richard,

Thanks for the feedback, I will proceed as suggested and stay on the working version while a new version is release.

Thanks again!

Hello

As I wrote before this is really strange. It looks very similar to an issue we had on RDM Linux in certain environments, but I can't see how the same problem could occur on macOS. So I'd like some more information, if possible.

I've attached a shell script to this post. It's zipped, so you'll need to unzip it. Assuming you unzipped it to your desktop, please do the following:

• Open Terminal.app

• Make the script executable

  • chmod +x ~/Desktop/rdm-env.sh

• Launch Remote Desktop Manager if not already running (can be any version)

• Back in Terminal.app, execute the script and redirect the output to a file

  • ~/Desktop/rdm-env.sh /Applications/Remote\ Desktop\ Manager.app > ~/Desktop/env.sh.out 2>&1

• This will create a file on your desktop "env.sh.out"

• Please send it to me by PM or to service@devolutions.net, mentioning this forum thread

You can study the contents of the shell script before you run it, but in summary what we are doing here;

• Capture basic user and system information (your username and user ID, your home directory, your macOS version)

• Verify the path to your documents folder (typically ~/Documents) and the permissions on that directory

• Call a macOS API to ask the system where your documents folder is

• Capture session and launch context (the logged-in console user, whether it's a remote login)

• Shows code-signing and entitlement information for RDM and list any related running processes

Please let me know if you have any questions or comments

Kind regards,

@Richard Markiewicz

Richard, shared the results 1:1

Hello

This is really strange. Since these are VMs I assume they're on your local network?

Can you check that Remote Desktop Manager has "Local Network Access" in System Settings > Privacy and Security > Local Network? In conjunction with that, try disabling the sandbox mode if not disabled already (RDM > Settings > Types > Remote Desktop (RDP) > Advanced > "Active Sandboxing" > "No".

Finally, if you try with the previous version, does it work? You can downloaded 2025.3.9.2 here. No need to install it, just close the currently running RDM and launch the old version direct from the .dmg.

Please let me know if something isn't clear or you have other questions

Kind regards,

@Richard Markiewicz

Hi There,

I tried setting the Active sandbox to NO and it did not work.

Yes, these VMs are in a local network where I'm connected to.

I just tried from the old version 2025.3.9.2 from link provided, and it does work like this!

Hello

It fails very early - is it just one server you can't connect to, or many? Are you able to connect with the Microsoft client (Windows App)?

Thanks and kind regards,

@Richard Markiewicz

Hi Richard,

I have 4 Windows VM configured as RDP, all of them fail to connect with the same error.

I tried connecting to them using console and also a Royal TSX and those work fine.

Hello

I'm sorry for the inconvenience. Can you please enable session logging as described here; reproduce the problem and send me the log by PM?

Please let me know if something isn't clear

Thanks and kind regards,

@Richard Markiewicz

Hi Richard,

Thanks for the quick reply,

I have reproduce the problem and the logs have been sent to support.

Hello,

After updating RDM to latest upadte, Feb 20, 2026. RDP is no longer working.

From the application logs, I see these constant errors:

[21/02/2026 13:52:20 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 13:52:19 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:17 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 11:53:16 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:07 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:07 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 11:48:50 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 11:48:49 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

Hello,

After recent update from RDM, RDP to windows VM is no longer working, from the application logs I see the following error:

[21/02/2026 13:52:20 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 13:52:19 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:17 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 11:53:16 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:07 - 2025.3.10.2 - 64-bit] Info: Remaining reconnection attempts: 4

[21/02/2026 11:53:07 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

[21/02/2026 11:48:50 - 2025.3.10.2 - 64-bit] Error: SECURITY_NEGO_CONNECT_FAILED (0x0002000C)

The error also appears when I try to connect to RDP and then it closes after 1 second.