Clipboard in headless mode status?

[mpack]

Thanks for reporting back, and thanks for the honesty.

[socratis]

Socratis, were you able to connect to Linux guest on standard 3389 port? I can do it only on alternative ports, maybe this is some limitation of RDP client and it expects only Windows-like RDP server on 3389 port?

As far as I can remember, yes. Just remember that you have to connect to the host[:port], not guest[:port]. But, I believe that you already have attempted exactly that, since you speak about "alternative ports". Maybe there's an RDP server already running, blocking the port? Firewall?

[geekster]

Well, I finally figured out the problem. I apologize and have to admit the problem isn't in Virtualbox, but it's rather a Windows limitation. Windows cannot share clipboard if more than one RDP-connection is active .

This does not seem to be the case for me at all. I recently added a comment to https://www.virtualbox.org/ticket/15986, Suncatcher's ticket. My problem is similar, as follows:

Windows 7 host
Ubuntu 16.04 64 guest

When connecting w/RDP from the host to the guest, I can copy from the host to the guest, but not the reverse. This is true when the only VM that is running is the Ubuntu VM.

As for windows not being able to share a clipboard if more than one RDP-connection is active, as I write this, I have 3 windows guests running on my windows 7(64)host, 2 guests are Win7/32 and 1 is Win2k (yes, 2k!), all of them headless. I am currently connected via RDP to all 3, and I can copy from and to each of them, between the host and the guests, between the guests and themselves, and between the guests and each other.

Interestingly, I currently also have the Ubuntu guest running and I am accessing it through RDP as well, and it allows me to copy from the host to the guest, but not the reverse. Again, this is true when it is the only VM running and when others are running as well.

Lastly, I have noticed that if I do NOT use RDP to connect to the Ubuntu guest, and use the VB GUI, I can use the clipboard both ways. However, if I then connect through RDP and attempt to copy from the guest to the host, it fails, and (this is the interesting part), having failed to copy from the guest to the host via RDP, if I then close RDP and "show" the gui again (without rebooting the guest), trying to copy from the guest to the host in the native VB GUI no longer works. If I then reboot the ubuntu guest and use the VB GUI, the clipboard works both ways... until I get RDP involved.

Please let me know if there are any files I can upload that might help to solve this mystery.

[Suncatcher]

I am currently connected via RDP to all 3, and I can copy from and to each of them, between the host and the guests, between the guests and themselves, and between the guests and each other.

Then I have no idea! For me this is mystery too
Suddenly my setup has broken again and clipboard doesn't work neither with 1 active session, nor with several. I cannot figure out what've changed so far - it's real mystery!
Maybe host OS matters too? Geekster, did you use Win 10 or Win 7 host for your three simultaneous RDP sessions? Previously I tested on Win7 host, but I have no access to it now and have only Win10 at hand.

[geekster]

As I stated, I am using a window 7 host. I realized after posting yesterday that the windows guests all have virtualbox's "Remote Desktop Server" DISabled, because windows natively supports RDP, and I just have that enabled on each guest. So if you haven't tried that (disabling VB's Remote Desktop Server and enabling remote desktop on the windows guests), I recommend it. So it seems that it is a problem with VB's Remote Desktop Server and Linux (in my case, ubuntu) guests.

[Suncatcher]

Well, that didn't help. Moreover, after trials to copy smth from guest to host I have 100% CPU utilization and clipboard has broken on host! Even PrintScreen is unfunctional!

clip.PNG (11.69 KiB) Viewed 8029 times

This seems to be severe Win10-related bug. Do you have possibility to test Win10 as RDP client?
I wrongly stated I used Win7 as a host, it's not true: previously I used Win10 as a host and WIn7 as a RDP client, and now I'm using WIn10 both as host and RDP client.

[geekster]

I just installed a win732 guest on a windows10(64) host, and through RDP, clipboard works great both ways. Again, this tells me it's something about a linux guest that's the problem.

[johny_mnemonic]

I can confirm everything geekster posted here.

Since I upgraded to new laptop and switched from Win 7 + Virtualbox 4.3.x to Win 10 + virtualbox 5.x VRDP clipboard stopped working and is since useless for me.

I thought, it could be my setup, or some issues connected with the fact, that both Win10 and Virtualbox 5.x were basically beta, when I joined (5/2015). But now almost two years later it still doesn't work any better.

I was heavily blaming my old Linux VM with Fedora 20 LXDE, so I didn't report anything and hoped that when I finally upgrade to newer Linux distro together with more mature Virtualbox, it will work again. Sadly I was wrong:-(

Yesterday I installed all new VM with Fedora 25 KDE and it has all symptoms @geekster described.
- Clipboard works fine when I use VM through Virtualbox UI
- Clipboard works host ->guest over MS RDP client
Randomly following happens:
- When MS RDP client connects, it breaks clipboard inside the VM in a way, that transfer from host to guest still works, but copying anything inside guest doesn't work.
- Even when RDP connection doesn't break clipboard inside VM, transfer of clipboard from guest to host doesn't work.
- Clipboard works fine both ways

Sometimes, I see already mentioned error in the log, but it is rare (like one line for last 24 hours and multiple RDP reconnections):
VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!

Two times, when I saw clipboard working both ways, I was trying these things:
1. killing and restarting of /usr/bin/VBoxClient --clipboard
2. reconnecting RDP session
3. saving VM state and waking it again

I can also confirm, that there is no relation to headless mode. VRDP clipboard is broken whether the VM is in normal mode or headless.
The worst thing is, that in case the RDP connection breaks clipboard transfer even for native virtualbox UI, usually I have to restart the OS in VM to bring it back Sometimes restarting /usr/bin/VBoxClient --clipboard helps, but not always.

My system details:
System installed on the HW (host): Windows 10 build 14393.726
System installed in VM (guest): Fedora 25 KDE
VirtualBox 5.1.14r112924

Latest RDP connection, which didn't have clipboeard working and even broken clipboard inside the VM produced this log:

Code: Select all

00:07:50.537838 VRDP: New connection: 
00:07:50.537984 VRDP: Connection opened (IPv4): 0
00:07:50.538220 VRDP: Negotiating security method with the client.
00:07:50.548723 VRDP: Connection closed: 0
00:07:50.593288 VRDP: New connection: 
00:07:50.593366 VRDP: Connection opened (IPv4): 1
00:07:50.593595 VRDP: Negotiating security method with the client.
00:07:50.602505 VRDP: Methods 0x0000001b
00:07:50.602541 VRDP: Channel: [rdpdr] [1004]. Accepted.
00:07:50.602548 VRDP: Channel: [rdpsnd] [1005]. Accepted.
00:07:50.602553 VRDP: Channel: [cliprdr] [1006]. Accepted.
00:07:50.602558 VRDP: Channel: [drdynvc] [1007]. Accepted.
00:07:50.602563 VRDP: Unsupported SEC_TAG: 0xC006/8. Skipping.
00:07:50.602568 VRDP: Unsupported SEC_TAG: 0xC00A/8. Skipping.
00:07:50.697520 VRDP: Client seems to be MSFT.
00:07:50.697559 VRDP: Logon: SPITY14 (127.0.0.1) build 14393. User: [] Domain: [] Screen: 0
00:07:50.697777 AUTH: User: []. Domain: []. Authentication type: [Null]
00:07:50.697792 AUTH: Access granted.
00:07:50.698780 VRDP: Enabling upstream audio.
00:07:50.699019 VBVA: VRDP acceleration has been requested.
00:07:50.703834 VRDP: SunFlsh disabled.
00:07:50.738368 VRDP: Input[2] enabled: 3
00:07:50.738415 VRDP: INPUT created for 2
00:07:50.740558 VRDP: SCARD enabled for 2
00:07:50.838431 VRDP: INPUT for 2: flags 0x0, ver 0x20000, contacts 10
00:07:50.838486 VRDP: INPUT closing for 2
00:07:50.848535 VRDP: Input[2] closed: 3
00:08:29.123671 VRDP: Logoff: SPITY14 (127.0.0.1) build 14393. User: [] Domain: [] Reason 0x0000.
00:08:29.123881 VRDP: Connection closed: 1
00:08:29.123994 VBVA: VRDP acceleration has been disabled.

So regarding what socratis is trying to point here, I would say that even in case he is right, that MS RDP client is to blame, it still means, something is broken also in vboxclient. It is undoubtedly able to cripple clipboard inside VM as a reaction to RDP connection and restarting it often fixes the clipboard inside the VM or the transfer of the clipboard in/out of VM.

I remember when I first discovered this issue, I tried multitude of RDP "clients" but neither solved the issue. But I suspect, that most of those clients are actually only pretending to be RDP clients and they are merely wrappers for MS RDP client found on the system.

I can also confirm, that having more than one RDP open doesn't affect the ability to use clipboard between them and the client machine. So to me this seems like specific issue on Suncatcher side, that is not relevant to this VRDP issue.

[socratis]

5.1.16 just came out. It contains the following in the release notes:

• rdesktop-vrdp: source code tarball fixes

[craig100]

Hope this isn't inappropriate observation for this thread, but this isn't just in Windows hosts. Version 5.1.18 r114002 (Qt5.5.1) with a W10 x64 guest in a Linux Mint (Cinnamon) x64 host with Clipboard set to "bidirectional", copy/paste initially works between Guest and Host. After some time, it stops working. Generally after the guest has been suspended with Ctrl-Q then "Save machine state" and brought back again. I'm now having to restart the guest to get the clipboard functionality back. This has been going on with Windows Guests for several years as I recall.

[socratis]

Generally after the guest has been suspended with Ctrl-Q then "Save machine state" and brought back again. I'm now having to restart the guest to get the clipboard functionality back.

Do you realize that this is a completely different problem?

[craig100]

The possibility of it being a related problem and therefore that mentioning it "may" assist in fault finding was the driver for me posting here. It being only a "possibility" is the reason I started with an apology if it wasn't appropriate. However, you'd be surprised what linkages there are between faults if you don't keep your focus too tight I won't be participating further in this thread.

Good luck with the solution.

[socratis]

I understand your motivation. But, if I were to use an analogy, a fever is not always the result of the same disease. Neither is a Windows BSOD the same for every case.

What you are describing is clearly a failure for the restore functionality. That deserves a thread of its own, with a proper, fully detailed description of the problem, along with the appropriate logs and replication details.

Good luck with the solution.

I believe that the solution was already provided and it was a client erroneous setup.

[johny_mnemonic]

I believe that the solution was already provided and it was a client erroneous setup.

Could you please point me to the solution you are talking about?
As I wrote in my post, I was unable to make VRDP working with clipboard since I upgraded to Windows 10 two years ago.
I had to resort back to using native vbox console, which is much worse then using RDP connection, so I am immensely interested in hearing about any kind of fix or workaround.

[socratis]

Could you please point me to the solution you are talking about?

It's in this thread. Did you read the whole thread where the OP came to the conclusion that his setup was faulty and it was causing the problem? Start from the first post.