Package Details: chrome-remote-desktop 110.0.5481.14-1

Git Clone URL: https://aur.archlinux.org/chrome-remote-desktop.git (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: https://remotedesktop.google.com
Keywords: Chrome Chromium Google Networking Remote
Licenses: BSD
Submitter: None
Maintainer: frealgagu
Last Packager: frealgagu
Votes: 121
Popularity: 0.56
First Submitted: 2014-04-27 23:43 (UTC)
Last Updated: 2023-02-01 23:11 (UTC)

Pinned Comments

frealgagu commented on 2020-12-05 22:38 (UTC)

I maintain the latest built package at:

https://github.com/frealgagu/archlinux.chrome-remote-desktop/releases/

victorbrca commented on 2020-04-03 01:04 (UTC)

Thanks @frealgagu for packaging this, @nightuser for the existing session patch and @Brinsky for the instructions.

I've compiled both instructions with screenshots and added it to my blog if anyone is having issues with the install. Otherwise, just follow the instructions in the comments by @Brinsky from 2019-12-06 13:58.

Brinsky commented on 2019-12-06 13:58 (UTC)

Here's how I got this working with the new web app (remotedesktop.google.com):

  1. Build and install the package
  2. run crd --setup
  3. (Optional) Configure execution of your preferred window manager in ~/.chrome-remote-desktop-session
  4. Go to http://remotedesktop.google.com/headless
  5. Click "next" and "authorize" through each instruction
  6. Copy/paste and run the provided "Debian" command, which should look like the following: DISPLAY= /opt/google/chrome-remote-desktop/start-host --code="<UNIQUE_CODE>" --redirect-url="<https://remotedesktop.google.com/_/oauthredirect>" --name=
  7. Set up a name and PIN
  8. Wait for successful output containing "Host ready to receive connections."
  9. Run crd --start

Latest Comments

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

JoKlaus commented on 2023-01-17 15:37 (UTC)

I have tried several times to install the package on a new machine with pamac on freshly built manjaro.

But this does not work because the file chrome-remote-desktop-108.0.5359.33.deb is not found (404).

But there is a Debian package for it, which can be installed after all.

However, the access to my desktop does not work with it either and the error message I get on a Windows computer says nothing about the cause.

By chance I found out - because I installed anyDesk as an alternative to chrome-remote-desktop and it also had the same problem and gave a better error message - through a YouTube article (https://www.youtube.com/watch?v=M_1UuMVYzkc) what the problem is:

In the configuration file etc/gdm/custom.conf I have the section:

[daemon] AutomaticLoginEnable=False

Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false

replaced by: [daemon] AutomaticLoginEnable=False

Uncomment the line below to force the login screen to use Xorg

WaylandEnable=false

Enable automatic login

AutomaticLoginEnable = true AutomaticLogin = $USERNAME

Now the chrome-remote-desktop-connection works, too, where I provide my Linux-desktop.

However, I don't know if changing this configuration doesn't have side effects.

Translated with www.DeepL.com/Translator (free version)

ewuplse01 commented on 2022-12-11 02:47 (UTC)

Fedora has a similar problem with Xorg, since there is no standard location for the Xorg binary. In Fedora, the Xorg binary is in /usr/libexec/Xorg. Google apparently makes no effort to support chrome-remote-desktop in any linux distributions other than Debian, which is obvious when you go to the setup page https://remotedesktop.google.com/headless.

tonyx commented on 2022-12-10 13:53 (UTC)

It goes permanently offline right after I add my device, any idea how to fix this? I tried everything and it still won't work.

clueo8 commented on 2022-12-07 15:56 (UTC)

Noticed after updating to the latest version the service would not start up, the fix for me was to install xf86-video-dummy and then crd --start worked like a charm.

ewuplse01 commented on 2022-12-07 14:22 (UTC) (edited on 2022-12-11 02:18 (UTC) by ewuplse01)

After installing xf86-video-dummy, I solved the Xorg wrapper problem described by @raduc by creating a symbolic link in /usr/lib/xorg/ to the Xorg binary. Debian installs the Xorg binary as /usr/lib/xorg/Xorg and arch installs the Xorg binary as /usr/lib/Xorg. I didn't want to change my path to circumvent the Xorg wrapper called by /usr/bin/Xorg because I was concerned that it could break something else. The following is from the Xorg.wrap man page. It explains why CRD, when installed as a service, needs to bypass Xorg.wrap, because it is creating a login session without a physical console, which the wrapper, by default, does not allow.

The Xorg X server may need root rights to function properly. To start the Xorg X server with these rights your system is using a suid root wrapper installed as /usr/lib/Xorg.wrap which will execute the real X server which is installed as /usr/lib/Xorg.

By default Xorg.wrap will autodetect if root rights are necessary, and if not it will drop its elevated rights before starting the real X server. By default Xorg.wrap will only allow executing the real X server from login sessions on a physical console.

cd /usr/lib/xorg
sudo ln -s ../Xorg Xorg

raduc commented on 2022-12-07 01:13 (UTC)

The problem is that Xorg wrapper is used instead of the binary. There is a workaround for Debian in: https://chromium-review.googlesource.com/c/chromium/src/+/3562121

But on Arch the Xorg binary is in /usr/lib, not in /usr/lib/xorg so the workaround does not work.

One way to make it work is to set /usr/lib to be first in path, before /usr/bin (so the binary /usr/lib/Xorg is used instead of the wrapper /usr/bin/Xorg): export PATH=/usr/lib:$PATH

Another way would be to patch linux_me2me_host.py to have: xorg_binary = "/usr/lib/Xorg";

Hope it helps.

ewuplse01 commented on 2022-12-07 00:14 (UTC) (edited on 2022-12-07 00:29 (UTC) by ewuplse01)

Version 108, by default, uses the debian package xserver-xorg-video-dummy instead of Xvfb for the headless virtual X display. I could not get CRD to work with Xorg, but I was able to revert to Xvfb by setting the CHROME_REMOTE_DESKTOP_USE_XVFB environment variable in .profile.

The following link explains this change which has been in the works since 2016.

https://bugs.chromium.org/p/chromium/issues/detail?id=596125

elppans commented on 2022-12-02 22:10 (UTC)

I made my configuration based on Brinsky's comment and it worked:

1. Build and install the package
2. run crd --setup
3. (Optional) Configure execution of your preferred window manager in ~/.chrome-remote-desktop-session
4. Go to http://remotedesktop.google.com/headless
5. Click "next" and "authorize" through each instruction
6. Copy/paste and run the provided "Debian" command, which should look like the following:
DISPLAY= /opt/google/chrome-remote-desktop/start-host --code="<UNIQUE_CODE>" --redirect-url="<https://remotedesktop.google.com/_/oauthredirect>" --name=

7. Set up a name and PIN
8. Activate and start the service:

sudo systemctl enable chrome-remote-desktop@"$USER".service
sudo systemctl start chrome-remote-desktop@"$USER".service
systemctl status chrome-remote-desktop@"$USER".service

Romeo4k commented on 2022-06-14 17:25 (UTC)

@gameslayer the comment from @ewuplse01 is useful and fixed it for me: pacman -S libutempter