github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #103] Clipboard does not work #78

New issue

Closed

opened 2026-05-05 05:00:13 -06:00 by gitea-mirror · 14 comments

gitea-mirror commented

2026-05-05 05:00:13 -06:00

Owner

Originally created by @funnym0nk3y on GitHub (Jul 29, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/103

Operating Systems

Server: Win10 64bit

Client: Win10 64bit

Barrier Version

2.1.0

Steps to reproduce bug

When running the software at both PCs there ist a problem with the clipboard. As the configuration states, there ist the possibility to transfer files via Drag-n-Drop between the machines. But when trying to do so, grabbing the file on the client works, but the release does not on the server. Also, when cutting on the client, the server does not recieve anything in it's clipboard. This problem existed also in Synergy.

Originally created by @funnym0nk3y on GitHub (Jul 29, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/103 ### Operating Systems ### Server: Win10 64bit Client: Win10 64bit ### Barrier Version ### 2.1.0 ### Steps to reproduce bug ### When running the software at both PCs there ist a problem with the clipboard. As the configuration states, there ist the possibility to transfer files via Drag-n-Drop between the machines. But when trying to do so, grabbing the file on the client works, but the release does not on the server. Also, when cutting on the client, the server does not recieve anything in it's clipboard. This problem existed also in Synergy.

gitea-mirror

2026-05-05 05:00:13 -06:00

closed this issue
added the
bug

windows
labels

gitea-mirror commented

2026-05-05 05:00:21 -06:00

Author

Owner

@nsk7even commented on GitHub (Oct 8, 2018):

You may check my issue where I found out that the automatic elevation on the client side was responsible for the clipboard stopped working: https://github.com/debauchee/barrier/issues/141

@nsk7even commented on GitHub (Oct 8, 2018): You may check my issue where I found out that the automatic elevation on the client side was responsible for the clipboard stopped working: https://github.com/debauchee/barrier/issues/141

gitea-mirror commented

2026-05-05 05:00:22 -06:00

Author

Owner

@panaut0lordv commented on GitHub (Aug 11, 2019):

It was also happening to me, both on latest Barrier and Synergy release Synergy_v1.9.0_rc3.msi (just copied that from the Windows VM via Barrier client! I am so happy :D).

However, while workaround works which means I'm no longer using Barrier LOCAL SYSTEM service (I've put it in disabled state for now) but rather "synergyc.exe IP" in my AppData/Roaming/Ms/Win/Start Menu/Programs/Startup I still have an issue.
As you might guess such a "solution" no longer allows me to click inside elevated popups or login back to my user's session (e.g. after using RDP to click an elevated popup).
Any tips on how to deal with it?
Preferably with software workaround, not simply keeping dedicated USB mouse passed through to my VM.

BTW I'm reading through this file https://github.com/debauchee/barrier/blob/master/src/lib/platform/MSWindowsClipboard.h
and one thing makes me wonder about that behaviour… because what I actually got wasn't a clipboard that wasn't updated - it was an empty clipboard. Does that help?

@panaut0lordv commented on GitHub (Aug 11, 2019): It was also happening to me, both on latest Barrier and Synergy release Synergy_v1.9.0_rc3.msi (just copied that from the Windows VM via Barrier client! I am so happy :D). However, while workaround works which means I'm no longer using Barrier LOCAL SYSTEM service (I've put it in disabled state for now) but rather "synergyc.exe IP" in my AppData/Roaming/Ms/Win/Start Menu/Programs/Startup I still have an issue. As you might guess such a "solution" no longer allows me to click inside elevated popups or login back to my user's session (e.g. after using RDP to click an elevated popup). Any tips on how to deal with it? Preferably with software workaround, not simply keeping dedicated USB mouse passed through to my VM. BTW I'm reading through this file https://github.com/debauchee/barrier/blob/master/src/lib/platform/MSWindowsClipboard.h and one thing makes me wonder about that behaviour… because what I actually got wasn't a clipboard that wasn't updated - it was an empty clipboard. Does that help?

gitea-mirror commented

2026-05-05 05:00:26 -06:00

Author

Owner

@panaut0lordv commented on GitHub (Nov 3, 2019):

Referenced issue points that was fixed for user with 2.3.2 but is still affects me.

Server is Arch:
usr/bin/barriers --version
barriers 2.3.2-RELEASE
Protocol version 1.6

Client is Win10:
2.3.2-snapshot-210c2b70

Message on Windows client is:
clipboard changed: lost ownership

@panaut0lordv commented on GitHub (Nov 3, 2019): Referenced issue points that was fixed for user with 2.3.2 but is still affects me. Server is Arch: usr/bin/barriers --version barriers 2.3.2-RELEASE Protocol version 1.6 Client is Win10: 2.3.2-snapshot-210c2b70 Message on Windows client is: clipboard changed: lost ownership

gitea-mirror commented

2026-05-05 05:00:29 -06:00

Author

Owner

@andrejrcarvalho commented on GitHub (Jun 9, 2020):

I'm with the same problem. I'm runnig the server in a Windows 10 and the client on a Ubuntu. I have notice that the clipboard stops working when I copy something from de client.

@andrejrcarvalho commented on GitHub (Jun 9, 2020): I'm with the same problem. I'm runnig the server in a Windows 10 and the client on a Ubuntu. I have notice that the clipboard stops working when I copy something from de client.

gitea-mirror commented

2026-05-05 05:00:34 -06:00

Author

Owner

@jamesgeddes commented on GitHub (Jul 14, 2020):

Same here, running Ubuntu and Win10 but cannot share clipboard between them. Would be super helpful if this worked.

@jamesgeddes commented on GitHub (Jul 14, 2020): Same here, running Ubuntu and Win10 but cannot share clipboard between them. Would be super helpful if this worked.

gitea-mirror commented

2026-05-05 05:00:36 -06:00

Author

Owner

@genebeck commented on GitHub (Aug 9, 2020):

Similar problem here. Version 2.3.2 Windows 10 host, Windows 10 and Linux Mint 19 clients. Clipboard works for a while then no updating. Restart the Barrier using the GUI on the server then all works for and hour or 2. Not drag or drop or copy files. This is using the clipboard for just text.

This is very irritating.

@genebeck commented on GitHub (Aug 9, 2020): Similar problem here. Version 2.3.2 Windows 10 host, Windows 10 and Linux Mint 19 clients. Clipboard works for a while then no updating. Restart the Barrier using the GUI on the server then all works for and hour or 2. Not drag or drop or copy files. This is using the clipboard for just text. This is very irritating.

gitea-mirror commented

2026-05-05 05:00:39 -06:00

Author

Owner

@shymega commented on GitHub (Aug 28, 2020):

Closing in favour of #855, as it has a similar mechanic to drag and drop -- in this case, clipboard sync of files.

@shymega commented on GitHub (Aug 28, 2020): Closing in favour of #855, as it has a similar mechanic to drag and drop -- in this case, clipboard sync of files.

gitea-mirror commented

2026-05-05 05:00:42 -06:00

Author

Owner

@jmrenouard commented on GitHub (Jan 28, 2022):

Hi,

This issue is still present in 2.4.0
Changing setting Elevate to As needed on the server side solves this issue

But iI don't figure it out why this is impacting copy/paste feature

Thanks for this great piece of software, Barrier is awesome !

Jean-Marie

@jmrenouard commented on GitHub (Jan 28, 2022): Hi, This issue is still present in 2.4.0 Changing setting Elevate to As needed on the server side solves this issue But iI don't figure it out why this is impacting copy/paste feature Thanks for this great piece of software, Barrier is awesome ! Jean-Marie

gitea-mirror commented

2026-05-05 05:00:47 -06:00

Author

Owner

@juankb1024 commented on GitHub (Jul 28, 2022):

I'm having the same issue in 2.4.0.

Using MacOS 12.4 Server and Windows 10 Client.

My problem is that the MacOS server does not have the "Elevate to" setting. Is this setting missing form the MacOS GUI?

Is there a way to force this setting in MacOS to see if it's related?

@juankb1024 commented on GitHub (Jul 28, 2022): I'm having the same issue in 2.4.0. Using MacOS 12.4 Server and Windows 10 Client. My problem is that the MacOS server does not have the "Elevate to" setting. Is this setting missing form the MacOS GUI? Is there a way to force this setting in MacOS to see if it's related?

gitea-mirror commented

2026-05-05 05:00:49 -06:00

Author

Owner

@JoeCodeswell commented on GitHub (Feb 14, 2023):

For me,
Barrier-Server: Windows 10
Barrier-Client: macOS 10.15.7

The clipboard works for a while & then stops working.

My WORKAROUND is to Reload the Server.

RESULT the clipboard starts working again.

Thanks for the GREAT PRODUCT.

Joe

@JoeCodeswell commented on GitHub (Feb 14, 2023): For me, Barrier-Server: Windows 10 Barrier-Client: macOS 10.15.7 The clipboard works for a while & then stops working. My WORKAROUND is to Reload the Server. RESULT the clipboard starts working again. Thanks for the GREAT PRODUCT. Joe

gitea-mirror commented

2026-05-05 05:00:51 -06:00

Author

Owner

@AdamStepinski0 commented on GitHub (Oct 31, 2023):

I had copy paste not working on Windows. I had two server instances running
UPDATE: two server instances were reason for problem with copy paste

@AdamStepinski0 commented on GitHub (Oct 31, 2023): I had copy paste not working on Windows. I had two server instances running UPDATE: two server instances were reason for problem with copy paste

gitea-mirror commented

2026-05-05 05:00:54 -06:00

Author

Owner

@shymega commented on GitHub (Oct 31, 2023):

I had copy paste not working on Windows. I had two server instances running

Barrier isn't maintained anymore. But more importantly, that's not how the architecture works - you need a server and client(s).

@shymega commented on GitHub (Oct 31, 2023): > I had copy paste not working on Windows. I had two server instances running Barrier isn't maintained anymore. But more importantly, that's not how the architecture works - you need a server and client(s).

gitea-mirror commented

2026-05-05 05:00:56 -06:00

Author

Owner

@jamesgeddes commented on GitHub (Dec 19, 2023):

@shymega When was the decision taken to stop maintaining barrier? I cannot see any advisements on that. Could it become an Apache Software Foundation or Linux Foundation project?

@jamesgeddes commented on GitHub (Dec 19, 2023): @shymega When was the decision taken to stop maintaining barrier? I cannot see any advisements on that. Could it become an Apache Software Foundation or Linux Foundation project?

gitea-mirror commented

2026-05-05 05:00:58 -06:00

Author

Owner

@shymega commented on GitHub (Dec 19, 2023):

@shymega When was the decision taken to stop maintaining barrier? I cannot see any advisements on that. Could it become an Apache Software Foundation or Linux Foundation project?

That decision was years back. We aren't obliged to advertise, and I explained numerous times on this tracker, but we won't be advertising on the Barrier repo. You can see the explanation here.

Input Leap is currently working on resolving the numerous bugs that have accumulated in Barrier, notably memory and CPU leaks, and updating to Qt 6 so that ARM64 can be supported on macOS.

And I don't think ASF or Linux Foundation will take Barrier on. In any case, Input Leap has diverged from Barrier and put more resources in, so it's not worth it. The differences are numerous, and it would be a waste of manpower.

@shymega commented on GitHub (Dec 19, 2023): > @shymega When was the decision taken to stop maintaining barrier? I cannot see any advisements on that. Could it become an Apache Software Foundation or Linux Foundation project? That decision was years back. We aren't obliged to advertise, and I explained numerous times on this tracker, but we won't be advertising on the Barrier repo. You can see the explanation [here](https://github.com/input-leap/input-leap/issues/1414). Input Leap is currently working on resolving the numerous bugs that have accumulated in Barrier, notably memory and CPU leaks, and updating to Qt 6 so that ARM64 can be supported on macOS. And I don't think ASF or Linux Foundation will take Barrier on. In any case, Input Leap has diverged from Barrier and put more resources in, so it's not worth it. The differences are numerous, and it would be a waste of manpower.

gitea-mirror referenced this issue

2026-05-05 07:56:18 -06:00

[PR #78] [CLOSED] Mention clipboard support in the README #1556