Tested this issue on 63.0.3239.132 using Ubuntu 14.04 with steps mentioned below.

1. In Ubuntu 17.10 installed extension and clicked on share
2. In Ubuntu 14.04 clicked on access and gave access code and observed  error "Unable to reach the host. This is probably due to the configuaration of the network you are using" 
3. Now in parent screen we observed  "chrome Remote desktop session is ended". Attaching screencast for reference

Hence forwarding this issue to Inhouse due to error observed during screenshare. Could someone from Inhouse team take a look into this issue.

Thanks!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/62fb6987a7076e770d5b3230b8976070cb2bab6b

commit 62fb6987a7076e770d5b3230b8976070cb2bab6b
Author: Prathmesh Prabhu <pprabhu@chromium.org>
Date: Wed Jan 10 23:50:20 2018

Add moblab pre-cq to moblab specific packages.

BUG=chromium:799788
BUG= chromium:800886 
TEST=None

Change-Id: I50ccaf04df0722f90b90509b7e61ae833607a983
Reviewed-on: https://chromium-review.googlesource.com/860906
Reviewed-by: Allen Li <ayatane@chromium.org>
Tested-by: Prathmesh Prabhu <pprabhu@chromium.org>

[add] https://crrev.com/62fb6987a7076e770d5b3230b8976070cb2bab6b/chromeos-base/autotest-server-deps/COMMIT-QUEUE.ini
[add] https://crrev.com/62fb6987a7076e770d5b3230b8976070cb2bab6b/chromeos-base/autotest-web-frontend/COMMIT-QUEUE.ini
[add] https://crrev.com/62fb6987a7076e770d5b3230b8976070cb2bab6b/chromeos-base/autotest-server/COMMIT-QUEUE.ini
[add] https://crrev.com/62fb6987a7076e770d5b3230b8976070cb2bab6b/chromeos-base/lucifer/COMMIT-QUEUE.ini

It looks like the host isn't installed properly (perhaps it got broken by a recent update). Lambros, can you provide instructions on how to reinstall?

To reinstall the package, I think you can run
  sudo apt-get install --reinstall chrome-remote-desktop

Or you could uninstall the package:
  sudo apt-get purge chrome-remote-desktop
then download and install the package from here:
https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb


Looking at the host log, it got as far as:
INFO:User 'xxxxxxxx' is already a member of 'chrome-remote-desktop'.
so it's not an elevation prompt issue.
It failed here:
ERROR:Could not execute /usr/lib64/chrome-remote-desktop/user-session: No such file or directory

The user-session binary is normally located at
/opt/google/chrome-remote-desktop/user-session

I don't know why the Python script is looking under /usr/lib64/ for this binary. From this line:
https://cs.chromium.org/chromium/src/remoting/host/linux/linux_me2me_host.py?l=94&rcl=0b162a3aca450eb760d04f235fedb291ef5be719

maybe SCRIPT_DIR got set to /usr/lib64/ ?

From these lines:
SCRIPT_PATH = os.path.abspath(sys.argv[0])
SCRIPT_DIR = os.path.dirname(SCRIPT_PATH)

So maybe the abspath() resolved to /usr/lib64/, perhaps because of a weird symlink: /opt/google/chrome-remote-desktop/ -> /usr/lib64/chrome-remote-desktop/ or similar?

Indeed, the script should look for user-session in the same location that the script itself is located. My understanding is that abspath() ignores symlinks and just does string-based manipulations, so it should only try to execute /usr/lib64/chrome-remote-desktop/user-session if it is invoked as /usr/lib64/chrome-remote-desktop/chrome-remote-desktop. (Perhaps realpath() would be better, here, since following symlinks may be desirable, but that's another issue.)

Looks like the initial reporter is using Fedora Core, which may install things in a different location. Perhaps they didn't realize we added a new binary they needed to package?

Comment #2 sounds like a completely different issue.

Good information, thanks! I hadn't realized the reporter was using FC - I apologize for my incorrect instructions for re-installing CRD.

Does sound like a packaging problem - the user-session binary should be installed in the same location as chrome-remote-desktop script, as setuid-root with these permissions:
-rwsr-xr-- 1 root chrome-remote-desktop   426104 Jan 31 19:05 user-session

This is somebody else's re-packaging of CRD, so I can't provide more detailed instructions on how to fix things.

mikeypk@ for better understanding could you please help us with the screen-cast of this issue.

Thanks...

kkaluri@: Apologies but I'm not sure what providing screen-cast means. Pointers to instructions on how to do that would be very helpful.

It appears that chrome-remote-desktop is present in /usr/lib64/chrome-remote-desktop, and user-session is missing from that directory.

Looking at
https://www.rpmfind.net/linux/rpm2html/search.php?query=chrome-remote-desktop

It looks like user-session is at
/etc/chromium/native-messaging-hosts/user-session
and there is another version of chrome-remote-desktop there. There is another copy at /etc/opt/chrome/native-messaging-hosts

I confirmed I find the 2 versions of user-session and 3 versions of chrome-remote-desktop script at these locations.

As far as I can tell, the chrome-remote-desktop under /etc/chromium/native-messaging-hosts, /etc/opt/chrome/native-messaging-hosts and /user/lib64/chrome-remote-desktop are the same.

Not sure if this is the right contact, but I see spot@fedoraproject.org and tpopela@redhat.com in the changelog from https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/aarch64/c/chrome-remote-desktop-64.0.3282.119-1.fc28.aarch64.html

Would it be appropriate to pull them into this bug thread?

Yes, I think it's worth making them aware of it.

Jamie: I can't figure out how to update this bug report to add people to the cc list. I don't know if it's a permissions issue, or if only the owner can update it.

lambroslambrou: Is it possible for you to add spot@fedoraproject.org and tpopela@redhat.com to the cc-list?

I'd prefer not to CC people without their permission. It would be better to contact them directly and make them aware of this bug thread so they can decide for themselves whether or not to make any changes to their packaging.