Package Details: chrome-remote-desktop 81.0.4044.60-1

Git Clone URL: (read-only, click to copy)
Package Base: chrome-remote-desktop
Description: Access other computers or allow another user to access your computer securely over the Internet
Upstream URL:
Keywords: Chrome Chromium Google Networking Remote
Licenses: BSD
Submitter: None
Maintainer: frealgagu
Last Packager: frealgagu
Votes: 109
Popularity: 2.66
First Submitted: 2014-04-27 23:43
Last Updated: 2020-03-25 17:37

Pinned Comments

frealgagu commented on 2019-08-12 22:41

@apepa you still need to download and install a package (.deb). This package downloads and converts to pacman for archlinux installation. Please don't flag this as outdated because is not.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

nightuser commented on 2020-03-22 14:51

Also, this patch adds an option to use the existing session (but it's disable by default for compatibility reasons).

To enable it, create ~/.config/chrome-remote-desktop/Xsession file with a proper session number (usually 0 or 1).

Unfortunately, I don't yet know how to transfer sound in this case (it'll probably require enabling public pulseaudio config).

nightuser commented on 2020-03-22 13:47

@frealgagu: Please, use the direct links to the versioned packages instead of the latest one. Fixed PKGBUILD: ).

They have the following format:


nightuser commented on 2020-03-22 13:32

Maybe we should run

/opt/google/chrome-remote-desktop/chrome-remote-desktop --size="${crd_size}" --start

with exec?

Also, the checksum changed again.

OdinEidolon commented on 2020-03-13 20:12

My issue was fixed: I also needed to uncomment the DBUS line in the .chrome-remote-desktop-session file. However, the systemd service does not work. It times out after a couple of minutes:

mar 13 19:35:55 sofia-pc systemd[831]: chrome-remote-desktop.service: Failed with result 'timeout'.
mar 13 19:35:55 sofia-pc systemd[831]: Failed to start "Chrome Remote Desktop host daemon".

Funny thing, while it is still working, CRD works fine, and it also works fine if I manually issue crd --start. Any idea?

OdinEidolon commented on 2020-03-13 16:43

It seems I can't get this working, neither with the online nor with the headless installation modes. The package builds fine, but when I try to start crd the session cannot start:

Launching X server and X session.
Starting Xvfb on display :20
X server is active.
Launching X session: ['/bin/sh', '/home/cestino/.chrome-remote-desktop-session']
Launching host process
['/opt/google/chrome-remote-desktop/chrome-remote-desktop-host', '--host-config=-', '--audio-pipe-name=/home/cestino/.config/chrome-remote-desktop/pulseaudio#2293cd462a/fifo_output', '--server-supports-exact-resize', '--ssh-auth-sockname=/tmp/chromoting.cestino.ssh_auth_sock', '--signal-parent']
wait() returned (397849,256)
Session process terminated
Failure count for 'session' is now 1
Terminating X server
Terminating host
Failure count for 'X server' is now 0
Failure count for 'host' is now 0
Waiting before relaunching
wait() returned (397848,256)
Waiting before relaunching

I use KDE and configured CRD to start using startplasma-x11, as it should be. Any idea on how to proceed?

frealgagu commented on 2020-03-06 17:18

@ansonx10 you're right, it's the way Windows and MAC behave. I don't want to affect users who have already installed, therefore, if most users prefer to have the current session, I will make the change. I want to know if there are reasons to use a different session instead of the current one.

ansonx10 commented on 2020-03-02 21:36

@frealgagu Well Chrome Remote Desktop users that come from other platforms, i.e. Windows and Mac, would expect it to behave the same way on Linux. (It lets you control your existing "session" on Windows and macOS) It would be more useful for me to be able to control my existing session by default. I can't personally think of a reason that I'd need to access my own computer in a new session, and in fact, creating a new session can cause problems for some software. Using VNC is always an option regardless, but the simplicity of remote connections in CRD is nice. In the spirit of simplicity (with the target demographic in mind), I'd advocate for current session being the default.

frealgagu commented on 2020-02-10 14:40

@Bakasura It's nice but I'm not sure what is the expected behavior for most users. Do you think you want to use always the active session or you want to open a new session instead? I think chrome-remote-desktop developers use the :20 in order to not affect the current session

Terence commented on 2020-02-08 22:44

@Bakasura nice!

Bakasura commented on 2020-02-08 17:17

@Terence I created a patch file

@frealgagu can you add?