Clipboard in headless mode status?

[Suncatcher]

I tried it with both Windows 7 and Ubuntu 12.04. Copy/paste via RDP works as advertised. Host2guest, guest2host, and guest2guest.

And I tested again as per your request and again it didn't work. Attaching the logs recorded during the test.

Ubuntu:
guest2guest: no
guest2host: no
host2guest: no interesting, because usually it works

Windows 7:
guest2guest: no
guest2host: no
host2guest: yes

[socratis]

00:00:00.396009 VRDP: TCP server listening on port 5555 (IPv4 and IPv6).

Not the default. Do your settings match? Most probably they do, otherwise you wouldn't even connect...

00:00:07.186689     Host path '\\VIVOBELARUS\downloads', map name 'Downloads', writable, automount=true, create_symlinks=false, missing=true
...
00:00:07.189174     Host path '\\VIVOBELARUS\software', map name 'Software', writable, automount=true, create_symlinks=false, missing=true
...
00:00:07.191523     Host path '\\Vivobelarus\mega', map name 'mega', writable, automount=true, create_symlinks=false, missing=true

You can't share these folders. Remove them, you are already getting errors.

00:00:09.524105 AUTH: User: [Suncatcher]. Domain: [DELLANO]. Authentication type: [External]
...
00:00:09.562026 VRDP: Clipboard: Unsupported packet type 0x0006!!!

I have no authentication and I get a 0x0007 packet type. No clue what it means.

And the culprit, the source of your problems:

00:00:57.478213 VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!
00:00:58.228342 VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!
...
00:01:22.090915 VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!
00:01:26.956474 VRDP: Guest requested clipboard format 0x00000001 that is not announced by VRDP clients. Ignoring the request!!!

Change your RDP viewer. Or your setup. Or both.
Maybe it has ... issues? But you already suspected that, right? It's not like you haven't seen this message before.

[socratis]

Now that I remembered, how did you manage that extra (actual) time entry? It really made the comparison between our logs a pain...

VirtualBox VM 5.1.10 r112026 win.amd64 (Nov 21 2016 16:43:40) release log
18:25:52.255152 00:00:00.281453 Log opened 2016-11-28T18:25:52.255152100Z
...

[Suncatcher]

how did you manage that extra (actual) time entry?]

It's VBOX_RELEASE_LOG_FLAGS variable
Really makes troubleshooting simpler for me as I usually remember actual time rather than time delta.

[Suncatcher]

00:00:07.186689 Host path '\\VIVOBELARUS\downloads', map name 'Downloads', writable, automount=true, create_symlinks=false, missing=true

You can't share these folders. Remove them, you are already getting errors.

Strange, but they worked fine.

Maybe it has ... issues? But you already suspected that, right? It's not like you haven't seen this message before.

Of course, I seen these messages. The droppings had supposedly another reason, non-RDP.

00:00:00.396009 VRDP: TCP server listening on port 5555 (IPv4 and IPv6)

Not the default. Do your settings match? Most probably they do, otherwise you wouldn't even connect...

I changed port to default, eliminated authentication but that didn't help. At least on Windows (will check Ubuntu later). The packet 0x0006 is still being thrown.
However, after setting port to default redirecting host local storage started to work (previously drives haven't been mapped), so I've made a small progress

Change your RDP viewer. Or your setup. Or both.

What do you imply under setup? I have the same viewer as you - Microsoft RDP: 8.0.35.

[socratis]

You can't share these folders. Remove them, you are already getting errors.

Strange, but they worked fine.

They can't work fine! By definition. They're not local to your host, ergo you can't share them! In fact if you run this VM normally, you'd get a popup error. Check your logs:

18:25:59.160408 00:00:07.186689 Host path '\\VIVOBELARUS\downloads', map name 'Downloads', writable, automount=true, create_symlinks=false, missing=true
18:25:59.161403 00:00:07.187580 ERROR [COM]: aRC=E_INVALIDARG (0x80070057) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Shared folder path '\\VIVOBELARUS\downloads' does not exist on the host}, preserve=false aResultDetail=0
18:25:59.161403 00:00:07.187798 Console: VM runtime error: fatal=false, errorID=BrokenSharedFolder message="The shared folder 'Downloads' could not be set up: Shared folder path '\\VIVOBELARUS\downloads' does not exist on the host.
18:25:59.161403 00:00:07.187799 The shared folder setup will not be complete. It is recommended to power down the virtual machine and fix the shared folder settings while the machine is not running"

Also:

The packet 0x0006 is still being thrown.

And I have no clue if it's good or bad. I'm seeing it too, so that's not a sign of failure.

I have the same viewer as you - Microsoft RDP: 8.0.35.

Yes, maybe, but mine is on a Mac. The one that I have on my other machine (which works BTW), is the native one for Windows 7 and it's version 6.3.9600. That one (Win7) has a setting for "Clipboard". The Mac one doesn't. So version number does not necessarily mean same features, I believe it's more targeted to the protocol version.

Again, try an alternative RDP client with the default setup, or check your existing setup, fix the errors and proceed. Once you do, we could continue this conversation. I believe, now more that ever, that it's your setup. You have to prove now that it's not.

[Suncatcher]

I was able to set up Windows guest headless on the default port but cannot do this for Ubuntu. I am trying to connect via IP and it always fails. Neither works telnet on 192.168.0.XX:3389.
But when I connect like localhost:4444 it works.
What could be the reason? Both guest machines have bridged adapters.

[socratis]

I believe that we have already covered that:

I believe, now more that ever, that it's your setup.

[socratis]

Any news on this? Were you able to get it going?

[Suncatcher]

Any news on this? Were you able to get it going?

Unfortunately no. I even replaced my router to make a cleaner test, but no luck.
I still cannot connect to Ubuntu via direct IP in bridged mode.

[socratis]

But can you connect to your Windows? I assume yes, since you didn't bring it up. Have you checked firewalls, obstacles and everything else in Ubuntu?

The main point is not Ubuntu or Windows. The main point is that if it works in one, the it's the setup of the other to blame. Ergo, it's not a VirtualBox bug and it should be closed as "Invalid" or "WorksForMe" because other people keep referencing an still open bug and it creates lots of confusion.

[Suncatcher]

because other people keep referencing an still open bug and it creates lots of confusion.

Let other users confirm or disapprove that clipboard works for them in headless mode, this should give me the key to the problem.

[socratis]

You can't even connect to the remote computer! How do you expect to verify or not a situation that doesn't even exist to begin with? Nobody has complained about it, except you. Your denial to close the ticket is outstanding.

Does it work on Windows? Yes or no please.

[Suncatcher]

No, it doesn't work.
If we speak about (client) setup as you often do, then it shouldn't work anywhere. However it works on physical machines. So one can come to a conclusion that it's VM-only problem.

[Suncatcher]

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 .
It was proven during my extensive tests with all types of machines (Linux and Windows). It is also true for any client, I tested both native Windows RDP client and alternative ones (Parallels).
That was my fault and that is the thing I never payed attention before that: I mostly used 2 RDP connections simultaneously and that was the pitfall, clipboard was blocked because of this fact and didn't function both inside guest and outside too. Will submit this issue to MS.

P. S. 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?