Cannot open mapped path on Ubuntu

[jpbaril]

I'm not able to open mapped remote shares on Ubuntu 19.04. I the trangui settings I have:

/downloads=smb://diskstation.local/downloads

I get the "Unable to execute" error and Nautilus does not open either.

1. Operating system: Ubuntu 19.04 with Nautilus 3.32 in Unity 7
2. Transmission Deamon : 2.94
3. Transmission Remote GUI : 5.17

The only workaround I found is to use:

/downloads=/run/user/1000/gvfs/smb-share:server=diskstation.local,share=downloads

[Donatzsky]

I have the same problem, but the gvfs workaround doesn't work either.

[FieryRider]

The same problem on ArchLinux with NFS share (downloaded files are on NAS; transmission-daemon is running on 1 pc that mounts the download dir as NFS share and I try to access the files from another pc where I've also mounted it as NFS share). After checking the code it seems to use Lazarus' OpenDocument() function which does nothing on ArchLinux with Gnome (haven't tested other). So NFS doesn't seem to be the problem. PS: I know nothing about Pascal. I just managed to install LazarusIDE and created new "Application" project with 1 button to which I added lclintf to the imports and executed OpenDocument('/home/myusername') on button press and nothing happened.

[admusin]

In case anyone else still stumbles on this issue, I managed to solve it for myself by hacking my way through the code (I never learned Pascal).

Basically, after upgrade to Debian Bullseye (running KDE Plasma), the binary from the tagged version 5.18, stopped working for me. The app would launch without any GUI, only a systray empty icon and when starting it via CLI I would get a string of errors: (transgui:111321): Gtk-CRITICAL **: 05:37:17.054: IA__gtk_widget_realize: assertion 'GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed

So I pulled the latest commit from the master branch, which after compiling, actually worked for me but at first run it gave the error detailed in issue #1354. So I merged the fix from there into the latest commit of the master branch, in order to get rid of that error and after recompiling, it went away.

However, at this point I stumbled upon the error described in this very issue. After a couple of hours of reading articles, perusing and playing with the code and recompiling, the original poster of issue #1218 lead me on the right track, which was to replace OpenDocument with OpenURL in the ELSE branch of the IF statement nested in the ELSE branch of the second iteration of {$ifdef mswindows}, in the ExecRemoteFile function. E.g.

{$ifdef mswindows}
if Userdef then
              begin
                    p := Format(FUserDefinedMenuParam, [s]);
                    s := FUserDefinedMenuEx;
              end ;
                    Result:=OpenURL(s, p);
{$else}
      if FLinuxOpenDoc = 0 then
          Result := OpenURL(s, p) 
          //Result := OpenDocument(s);
      else
          //Result := OpenDocument(s);
          Result := OpenURL(s, p);
{$endif mswindows} 

After recompiling, once more, I got rid of this annoying error.

I can't judge if this would help every Linux user out there (likely not) but just in case, I'm laying it out here, for anyone else who like me is looking for a way out of this Unable to execute error.

[kien-truong]

No need to edit the code just to use OpenURL, you can change the setting in .config/Transmission Remote GUI/transgui.ini

[Interface]
...
FileOpenDoc=0
...

[BEvgeniyS]

@kien-truong, Thanks for the hint, FileOpenDoc=0 solved the issue for me in KDE Plasma, smb:// links now work