Linux 2026.3.1.1: SFTP Open downloads the file but constructs an incorrect local path

Linux 2026.3.1.1: SFTP Open downloads the file but constructs an incorrect local path

avatar

Hello,
In Remote Desktop Manager for Linux, clicking Open on a remote file downloads it successfully, but no editor opens and no error is displayed.
Environment:

  • RDM 2026.3.1.1, 64-bit, DEB installation
  • Ubuntu 26.04.1 LTS
  • GNOME / Wayland
  • Default PHP file editor: VS Code

Steps to reproduce:

  1. Connect to a Linux server over SSH and open the SFTP pane.
  2. Navigate to a file such as /home/ubuntu/example/config/Config.php.
  3. Right-click the file and select Open.

The file is downloaded to:
/tmp/RDM/edit_<hash>/Config.php
However, the debug log reports the following (paths anonymized):
OpenEdit - Failed to find file at location: /tmp/RDM/edit_<hash>//home/ubuntu/example/config/Config.php
It appears that the full remote path is appended to the temporary directory where only the filename should be appended.
Additional checks:

  • Opening a local PHP file with xdg-open successfully launches VS Code.
  • An execve trace showed no editor or xdg-open process being launched during the failed Open action.
  • Creating a temporary directory symlink so the incorrect path resolves to the downloaded file made Open work immediately.
  • Automatic upload after editing has not been tested.

Updating from 2026.3.0.5 to 2026.3.1.1 fixed the separate issue where the SFTP pane would not open from the SSH toolbar, but this file-opening issue remains.
Could you investigate the local path construction in the SFTP Open action?

All Comments (1)

avatar

Hello,
Thank you for the detailed report, it made this very quick to track down.
I was able to reproduce the issue on our side with Remote Desktop Manager for Linux 2026.3.1.1.
When I click Open on a file in a subfolder of the SFTP pane, the file downloads to /tmp/RDM, but no editor opens and no error is shown.
This matches what you found in the debug log: RDM looks for the file under the full remote path instead of only the file name.
I am sending this to our QA team with your steps and findings, and I will update this thread as soon as I have news on a fix.
In the meantime, your symlink workaround is the only one confirmed to work.
Thank you again for your patience.
Best regards,

Carl Marien