Terminal Server Client isn't able to copy to/from clipboard

Bug #94743 reported by Thomas Novin
90
This bug affects 9 people
Affects Status Importance Assigned to Milestone
tsclient
Unknown
Unknown
tsclient (Ubuntu)
Invalid
Low
Unassigned
Nominated for Lucid by John Sanders

Bug Description

Binary package hint: grdesktop

If I add something to the clipboard from for example gedit, gterminal and then try to paste it into my Terminal Server Client connection, that does not work. If I try it the other way around, I see the same problem. I have tried with RDP and VNC.

ProblemType: Bug
Architecture: i386
Date: Thu Mar 22 13:42:25 2007
DistroRelease: Ubuntu 7.04
Uname: Linux pc-thnov-ubuntu 2.6.20-12-generic #2 SMP Sun Mar 18 03:07:14 UTC 2007 i686 GNU/Linux

Revision history for this message
Thomas Novin (thomasn80) wrote :

Shouldn't this bug be marked with Affects: rdesktop? If I run the application alone from command-line I will still have the same problem.

rdesktop -uAdministrator -g1024x768 -rsound:off -k sv -4 <IP>

Revision history for this message
Thomas Novin (thomasn80) wrote :

..but as I wrote myself I also have the bug under VNC. Sorry :)

Revision history for this message
Jonh Wendell (wendell) wrote :

rdesktop does support clipboard feature. Try 'rdesktop' in a terminal and you'll see that option ('-r clipboard:[off|PRIMARYCLIPBOARD|CLIPBOARD]').

tsclient doesn't have a frontend for the clipboard option, so, this bug must be confirmed in tsclient.

Changed in tsclient:
importance: Undecided → Low
status: Unconfirmed → Confirmed
Revision history for this message
Jonh Wendell (wendell) wrote :

Fixed on upstream

Changed in tsclient:
status: Confirmed → Fix Committed
Revision history for this message
bpedman (bpedman) wrote :

So how do you get the fix from 'upstream'? I really hate not having this capability. Is there a way to get this from backports? or are those fixes only sent to backports if the status is FIX RELEASED?

Revision history for this message
Thomas Novin (thomasn80) wrote :

AFAIK this is only a problem if you don't choose RDPv5 (at least for rdesktop connections). That was my problem at least, that I had selected RDP (RDPv4) instead of RDPv5.

Revision history for this message
webograph (webograph) wrote :

tried it with ubuntu's rdesktop via ssh tunnel on a gentoo box's x server and vice versa.
result: the problem lies in the interaction between rdesktop and the x server or clipboard.
(ubuntu's rdesktop can copy/paste on gentoo x server, gentoo's rdesktop can't on ubuntu x server, pure gentoo works as well)

did not test vncviewer yet, lacking a remote server.

Revision history for this message
komputes (komputes) wrote :

I am also having issues with the clipboard across VNC. I think it keeps the content of the clipboard when connecting, but once the connection is established, there is no copy paste functionality between the local and remote desktops.

Revision history for this message
MountainX (dave-mountain) wrote :

I also noticed that RDPv5 is better. ...now I just have to deal with the fact that my swapped capslock and ctrl keys don't work at all over RDPvX. I can't do Ctrl-C or Ctrl-V now that I upgraded to Hardy.

Revision history for this message
|cyn| (geoffu) wrote :

RDPv5 doesn't fix it for me. I am back to using 'rdesktop -r clipboard:CLIPBOARD' directly from the shell. This is pretty much a show stopper for using linux when you have windows boxes in your organization. I know it seems like a small thing, but till evolution is stable with Exchange (and it's getting better, but still not close), we are stuck using TS, VMs or wine for email.

Shell scripts are not really acceptable when you manage 10+ clients running windows either.

I used the following to convert my rdp items into rdesktop shell scripts that I can then add to a drawer in gnome (note the ~/bin directory must exist):

cd ~/.tsclient
for i in *.rdp; do grep 'full address' $i | cut -d':' -f3 | while read j; do echo '#!/bin/sh' > ../bin/$i.sh; echo rdesktop -5 -f -r clipboard:CLIPBOARD $j >> ../bin/$i.sh; chmod 700 ../bin/$i.sh; done; done

Revision history for this message
David Colborne (oatworm) wrote :

I had the same problem on my laptop, and RDP5 did nothing - the problem, at least with me, was with Compiz. I turned off Desktop Effects (System->Preferences->Appearance->Visual Effects->None, then restart); ever since then, it's worked. I think Compiz is nerfing grdesktop's link with the X server somehow. Interestingly, I'm also noticing that my connection looks cleaner, meaning that I'm not losing text on my remote sessions anymore.

Revision history for this message
Chris Davis (chris-thedavislabs) wrote :

I'm using Ubuntu 8.10, and it appears that tsclient is reversing the RDP protocol version from the selection.

If I select RDPv5, rdesktop is called with -4. If I select RDP (version 4), I see -5 on the rdesktop command line and the clipboard works just fine.

Revision history for this message
Gary Mansell (garymansell) wrote :

I can confirm Chris Davis's comment that if you select RDP5 in the tsclient GUI, when you grep for the rdesktop process, you see that it is using protocol 4 rather and vice versa...

This is with Ubuntu 8.10 x86_64

Rgds

Revision history for this message
Jamie Jackson (jamiejackson) wrote :

Also confirming that selecting "RDP" from the select box gives the "-5" switch (wherein copy-paste works, albeit flaky*).
Similarly, selecting "RDPv5" from the select box gives the "-4" switch (wherein copy-paste doesn't work).

*I can only seem to copy from my local machine (ubuntu) to my remote machine (win2k3 server), but not from the remote machine to my local machine. Also, I've seen times when even the local to remote copy paste stops working.

rdesktop Version 1.6.0. Copyright (C) 1999-2008 Matthew Chapman.
tsclient version 0.150

Linux mercury 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux
Description: Ubuntu 8.10

Revision history for this message
RomanIvanov (ivanov-jr) wrote :

Xubuntu 8.10. for me copy\paste does not work for RDP, but works for RDPv5. I am connecting to my WinXP.

Revision history for this message
Robert Navarro (crshman) wrote :

I too confirm that selecting RDP rather than RDPv5 allows for clipboard usage.

Version 1.6.0. Copyright (C) 1999-2008 Matthew Chapman.

tsclient version 0.150

Linux mcepc 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 GNU/Linux

with compiz enabled

Revision history for this message
demonhill (simon-itstar) wrote :

Tested on my ubuntu 8.10
I found it in http://cutecomputer.wordpress.com/2007/01/03/howto-copy-paste-between-local-and-remote-desktop/

Go to the Window Server's Services , select Auto and start the below 3 services.
1. Network DDE DSDM
2. Network DDE
3. ClipBook

and back to your Linux PC Terminal Server Client , connect using RDP only.

Revision history for this message
pug (joe-taormina) wrote :

Copy and paste used to work some weeks ago. If I select connection via RDP from tsclient, then I can copy from Ubuntu host > WindowXP remote. But I can not copy and paste from WindowsXP remote > ubuntu host. If I select RDPv5, neither works.

I also tried the methods listed above, the services turned on, but they didn't work either.

Revision history for this message
Daniel Burton (lordofthebrambles) wrote :

I am having this issue as well, but only when I open an rdesktop session in full-screen mode. It does not matter whether I use RDPv4 or RDPv5. Likewise, it does not matter whether or not I have visual effects enabled. I have the issue both when using rdesktop on the command line and when using tsclient. I have tried all of the possible "-r CLIPBOARD" settings on the command line, and none of the possible options work.

I am using Ubuntu 9.04, rdesktop version 1.6.0-2ubuntu1, and tsclient version 0.150-1ubuntu7~lpbug183076.

Revision history for this message
broe (erich-rupp) wrote :

i can confirm that tsclient reverses the selection of the RDP-version, e.g. selecting RDPv5 results in "-4" in the command line, selecting RDP gives "-5" (and then the clipboard works for me)

Revision history for this message
merrithewi (ian-merrithew) wrote :

In 9.04, I was able to copy/paste without any difficulty. Since upgrading to 9.10 it's toast. Selecting "RDP" gets no copy/paste functionality, which is as it was in 9.04 anyway. Selecting "RDPv5" gets a non-working paste function. That is, I can copy from Ubuntu, and the "Paste" option becomes available in the remote session's windows, but nothing actually pastes when I click it.

Revision history for this message
lhotari (lartsa) wrote :

Workaround for 9.10, install tsclient from 9.04: http://packages.ubuntu.com/intrepid/tsclient

Revision history for this message
sander79 (sahondema) wrote :

Dunno if anyone still needs it. Using tsclient, I save the RDP session and added the clipboard:CLIPBOARD to the saved file on my desktop. Otherwise it won't work between RDP/virtualbox/local sessions.

Revision history for this message
Robert (anon-razza) wrote :

Thanks Sander :) Just what I needed to fix it.

Revision history for this message
Luca A (luca-azzalini) wrote :

Thanks Sander! I have got the same problem and solved it with your hint!

Revision history for this message
Catapult (ubunt2+launchpad) wrote :

sander, robert, luca a:

I added
clipboard:CLIPBOARD

to my .rdp file.

I then open that up in Terminal Server Client, but there is still no copy/paste across remote<-->local.

Please help.

Revision history for this message
MacRules (macrules) wrote :

Like posted earlier, in tsclient choose RDPv5 as protocol.
I am on 10.10 and this enabled c/p for me.
From rdesktop it works without mods, when I run it from the terminal like:
rdesktop -g 1024x768 servername.dom.ain

hope that helps

Revision history for this message
Jeremy Bícha (jbicha) wrote :

Thank you for reporting this bug. tsclient has been removed from the Ubuntu 11.10 archives. The software has not had a new release in years and was no longer being maintained. Unfortunately that means this bug won't be fixed.

Changed in tsclient (Ubuntu):
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.