Simon Duguay Létourneau

Hello,

We initially chose Flathub because, at the time we decided to provide a Flatpak package, it seemed like the simplest and most established way to distribute it.

Over time, maintaining the Flathub package became increasingly difficult. Some new RDM features required Flatpak-specific implementations or workarounds that were not necessary for our other Linux packages. We also encountered a number of issues that were specific to the Flatpak version because of the restrictions we had to respect.

The main limitation for us was Flathub's sandboxing model. Applications are expected to request the narrowest permissions possible, which can conflict with RDM's purpose. RDM may need access to SSH configuration, certificates, smart cards, local sockets, devices, network resources, user files, system services and other applications installed on the host machine..

Some of these limitations were already present when we originally chose Flathub, but given RDM's functionality at the time, they were not significant enough to be a concern. As RDM evolved and gained more integrations and capabilities, those limitations became increasingly problematic.

More recently, another important factor was our decision to maintain two release branches: the current release and an Extended Maintenance Release. Flathub's distribution model does not fit well with the way we want to maintain and publish those two versions.

Moving to our own Flatpak repository gives us more control over the package, permissions, release channels, and deployment process.

Regarding the deployment issue and the incorrect URL in our documentation, those were issues on our side during the transition to the new repository. We’re sorry for the inconvenience this caused. The required fixes have now been applied, including the correction to the documentation.

Best regards,

Hi Michael,

Thanks for reaching out and for bringing this to us!

We recently moved Remote Desktop Manager from Flathub to our own Flatpak repository because of limitations imposed by Flathub. Maintaining the application there had become difficult and often required workarounds to ensure that the Flatpak version behaved as closely as possible to the native RDM application. This change simplifies the development process and helps prevent issues that affect only the Flatpak version. We don't plan on putting it back on Flathub, unless there's a good reason for it.

Regarding the installation issues, you are correct that both documented methods currently have problems.

The first issue, involving the .flatpakref installation method, was caused by a deployment problem in our release process. A temporary fix has now been applied, so you can retry the following:

flatpak install https://cdn.devolutions.net/download/Linux/RDM/com.devolutions.remotedesktopmanager.current.flatpakref

The second issue is an incorrect URL in our documentation. The correct repository URL is:

https://cdn.devolutions.net/flatpak/devolutions.flatpakrepo

You can add it using:

flatpak remote-add --if-not-exists devolutions https://cdn.devolutions.net/flatpak/devolutions.flatpakrepo

We will correct the documentation shortly, and the deployment issue should also be permanently resolved later this week.

Sorry for the inconvenience. If you or other users think of a reason for us to go back on Flathub, we will reconsider this decision.

Best regards,

Hello,

Are you using the Flatpak version of RDM? This can happen because Flatpak apps run inside a container.

If so, you can work around the issue with one of the following commands:

For the current user only:

flatpak override --user --filesystem=host com.devolutions.remotedesktopmanager

System-wide, for all users:

sudo flatpak override --filesystem=host com.devolutions.remotedesktopmanager

Regards,

Hello,

I identified an issue when using xfreerdp and RDM via Flatpak and implemented a fix that will be included in the next release.

In the meantime, you can work around the problem by granting Flatpak full filesystem access with the following command:

sudo flatpak override --filesystem=host com.devolutions.remotedesktopmanager

Note: you may need to type the command manually in your terminal, as copy/paste doesn’t seem to work correctly.

Best regards,

Hello,

I was able to reproduce the issue you reported, and I can confirm it has been fixed on our side.

The fix will be included in our next release (2026.1).

Best regards,

Hello,

Are you launching your connections with Properties → Display → External setted? If so, you’ll need to grant the Flatpak access to the folder that contains xfreerdp, like this:

flatpak override --user --filesystem=/path/to/xfreerdp com.devolutions.remotedesktopmanager

Or

sudo flatpak override --filesystem=/path/to/xfreerdp com.devolutions.remotedesktopmanager

Best regards,

Hello Rob,

Have you also tried running the following command?

sudo flatpak override --env=GTK_THEME=Adwaita:dark net.devolutions.RDM

Regards,

Hello,

Version 2025.3.2.3 is now out.

Let us know if you continue to get the error.

Best regards,

Hello Victor,

You’re welcome!

The hotfix is scheduled to be released tomorrow morning.

In the meantime, you can try working around the issue by launching RDM with:

XDG_DOCUMENTS_DIR=$HOME/Documents remotedesktopmanager

If that still doesn’t work and you’d like to downgrade via yay, you can first check which versions are available in your cache:

ls -1 /var/cache/pacman/pkg | grep -i remotedesktopmanager

Then install the version you want with:

sudo pacman -U /var/cache/pacman/pkg/remotedesktopmanager-<version>-<arch>.pkg.tar.zst

Hello Victor,

We’ve received reports from Flatpak users that look very similar to what you’re experiencing, even if you’re not using Flatpak.

https://forum.devolutions.net/topics/52131/fedora-43-kde-flatpak-2025322-previously-working-rdp-sessions-now-fail

Once the hotfix is published, please let us know if the issue occurs again on your side.

Best regards,

Hello,

We’ve identified the root cause of the issue and will be publishing a hotfix soon.

As a workaround, you can install the latest Flatpak version and run it with the following command:

flatpak run --env=XDG_DOCUMENTS_DIR=$HOME/.var/app/com.devolutions.remotedesktopmanager/config com.devolutions.remotedesktopmanager

Regards,

Hello,

We’re actively working on it, and we suspect the issue is related to SSL/TLS, since disabling TLS on the remote server resolves the problem.

We’ll share an update as soon as we have more information.

Best regards,

Flatpak applications run in a sandbox and don’t have access to all folders by default. To work around this, you can grant the Flatpak permission to access a specific folder using flatpak override:

User install (per-user):

flatpak override --user --filesystem=/path/to/folder com.devolutions.remotedesktopamanager

System install (all users):

flatpak override --filesystem=/path/to/folder com.devolutions.remotedesktopamanager

If you want to grant access to all folders, use --filesystem=host instead of a path.

Hello,

You can view the list of previous versions with the following command:

flatpak remote-info --log flathub com.devolutions.remotedesktopmanager

To downgrade to version 2025.3.1.1, run:

flatpak update --commit=2d69ca95f9203174f7e305875d8b7d7fbd75015f42f26191cc693346bed605ce com.devolutions.remotedesktopmanager

Regards,

Hello Kyle,

I’m not sure why you’re seeing the Gtk-WARNING: Invalid text buffer iterator message.

Does it only appear when launching an RDP session? Also, are you using the performance profiler under Help → Performance profiling?

Regards,

Hello Kyle,

Can you try launching Remote Desktop Manager with this environment variable set? This should print more RDP-related details in the terminal.

WLOG_LEVEL=DEBUG remotedesktopmanager

Best regards,

Hello,

Could you please check which version of xfreerdp you’re using?

You can do this by running:

• xfreerdp --version or

• xfreerdp3 --version

It looks like you may be using version 3.18, which has a known issue. This can be resolved by either downgrading or upgrading xfreerdp to a version lower than 3.18 or greater than or equal to 3.19.1.

Best regards,

Hello,

The /usr/share/themes directory can’t be used with Flatpak. Try to install your themes in either ~/.themes or ~/.local/share/themes, and then apply the override.

Regards,

Hello,

I’ve looked into it and identified something that may have caused this. Our Flatpak previously included the filesystem=xdg-run/keyring option, but it was removed by mistake.

This will be fixed in the next update.

Regards,

Hello,

To resolve this issue, please run one of the following commands, depending on your installation type.

For a user installation:

flatpak override --user --filesystem=~/.ssh com.devolutions.remotedesktopmanager

For a system-wide installation:

sudo flatpak override --filesystem=~/.ssh com.devolutions.remotedesktopmanager

This problem occurs because Flatpak runs applications in a sandboxed environment and does not have access to the ~/.ssh folder by default.

Best regards,

Hello,

One reason it may work out of the box for other Flatpak applications is that they are configured with broader filesystem access, whereas ours is more restricted by default.

If you only want to use the Adwaita-dark theme, you can install org.gtk.Gtk3theme.Adwaita-dark and it should work without changing the GTK_THEME variable.

For other themes, keep in mind that Flatpak runs applications in a sandboxed environment, so it doesn’t have access to some folders where GTK themes are stored. To allow access, you can run the following commands for a user installation:

flatpak override --user --filesystem=~/.themes com.devolutions.remotedesktopmanager
flatpak override --user --filesystem=~/.local/share/themes com.devolutions.remotedesktopmanager

For a system-wide installation, use:

sudo flatpak override --filesystem=~/.themes com.devolutions.remotedesktopmanager
sudo flatpak override --filesystem=~/.local/share/themes com.devolutions.remotedesktopmanager

Please make sure to revert any changes you previously applied with Flatseal before trying this.

Let me know if this resolves the issue.

Best regards,

Hi Rod,

The issue you reported has been fixed in version 2025.3.0.9.

Thank you for your patience and for bringing this to our attention!

Best regards,

Hello @christophjander,

Regarding your freezing issue, it appears to occur primarily when using the GNOME desktop environment, especially under Wayland. The problem seems to have started when we began integrating Avalonia into our app. This is a known issue, but for now, we’re waiting for Avalonia to fully support Wayland (it currently runs through XWayland, which can lead to issues on some distributions, primarily those using GNOME). I recently switched to Kubuntu, which uses the KDE desktop environment, and I haven’t experienced this issue since.

For your RDP issue, you can obtain more detailed RDP logs by running the following command:

WLOG_LEVEL=DEBUG flatpak run com.devolutions.remotedesktopmanager

Best regards,

Hello Rod,

I’ve finally been able to reproduce the issue you encountered.

Clipboard synchronization works by detecting changes made to the clipboard and sending them to the RDP session, even when RDM isn’t focused. However, it turns out that on some Linux distributions, the clipboard can only be updated when RDM is in focus. This explains why copying content within RDM works correctly, while copying something from another application, such as a web browser, doesn’t get sent to the RDP session.

I’m currently working on a fix to ensure clipboard synchronization behaves consistently across all Linux distributions.

Best regards,

Hello @rodneylane888,

I tested on CachyOS KDE on wayland but wasn’t able to reproduce the issue on my side. Could you let me know which operating system the remote server is running?