To expand on the original post...

I uninstalled CRD from the Mac and reinstalled to ensure the latest version was in use. The CFBundleVersion reported in /Library/PrivilegedHelperTools/ChromeRemoteDesktopHost.bundle/Contents/Info.plist is 58.0.3029.96.

After testing, the behavior was slightly different. When the login screen is displayed the remoting_me2me_host daemon is running and the computer is accessible remotely. If I log in as the admin user that I installed CRD and enabled remote access as, the remoting_me2me_host process is killed and respawned with a new PID as a result of the login process. If I then log out the remoting_me2me_host process is again killed and respawned once the login screen is back up. If I log in as any other user, administrator or not, remoting_me2me_host is killed and never respawned. This effectively disables remote access.

If I go to the Chrome Remote Desktop Host Preferences pane while logged in as one of these users, remote connections cannot be enabled. The pane simply says "Remote connections to this computer are disabled". There is a single button that says "Disable Remote Connections". So the button is reporting an inaccurate state and it's greyed out. So essentially nothing can be done in this pane. This same behavior is reference in  Issue 617407 .

Here's the progression as shown through a series of ps commands:

Computer has just been restarted an is sitting at the login screen:
macbook07:~ admin$ ps -awwx | grep remoting
  256 ??         0:00.18 /Library/PrivilegedHelperTools/ChromeRemoteDesktopHost.bundle/Contents/MacOS/remoting_me2me_host --host-config=/Library/PrivilegedHelperTools/org.chromium.chromoting.json --ssh-auth-sockname=/tmp/chromoting.root.ssh_auth_sock
  301 ttys000    0:00.00 grep remoting


I log in as any user other then the user who initially installed CRD and enabled remote connections:
macbook07:~ admin$ ps -awwx | grep remoting
  337 ttys000    0:00.00 grep remoting


I log out and the computer is back at the login screen:
macbook07:~ admin$ ps -awwx | grep remoting
  497 ??         0:00.16 /Library/PrivilegedHelperTools/ChromeRemoteDesktopHost.bundle/Contents/MacOS/remoting_me2me_host --host-config=/Library/PrivilegedHelperTools/org.chromium.chromoting.json --ssh-auth-sockname=/tmp/chromoting.root.ssh_auth_sock
  512 ttys000    0:00.00 grep remoting


I login as the user who initially installed CRD and enabled remote connections:
macbook07:~ admin$ ps -awwx | grep remoting
  629 ??         0:00.04 /Library/PrivilegedHelperTools/ChromeRemoteDesktopHost.bundle/Contents/MacOS/remoting_me2me_host --host-config=/Library/PrivilegedHelperTools/org.chromium.chromoting.json --ssh-auth-sockname=/tmp/chromoting.admin.ssh_auth_sock
  637 ttys000    0:00.00 grep remoting



As you can see every login/logout event causes remoting_me2me_host to be killed. 

Deleted: crd.png 94.7 KB

	crd.png 94.7 KB View Download

After more testing this appears to be caused by the CRD config file not being readable by any users other than the user who initially enable remote connections.

When UserB logs into macOS the following entry is logged in the system log:

May  7 23:33:00 macbook07 remoting_me2me_host[2516]: Failed to read '/Library/PrivilegedHelperTools/org.chromium.chromoting.json': Permission denied

Viewing permissions on that file shows:
bash-3.2# ls -le org.chromium.chromoting.json
-rw-------+ 1 root  wheel  2012 May  6 00:08 org.chromium.chromoting.json
 0: user:admin allow read

So only root and admin can read the config file. Doing a 

chmod +a "UserB allow read" org.chromium.chromoting.json

appears to resolve the issue, but brings up the question of why does it work this way? It seems the devs are assuming that unattended access should be available only when the user who enabled remote connections is logged in (or when the login screen is up).

The issue seems to be out of TE-scope. Hence, adding the label TE-NeedsTriageHelp for further investigation.

Thanks...!!

The way the system is architected on Mac means that a new host process starts up for each local user session, but only the login screen (root) and the person who started that host are ACL'd to be able to read the config file. When the host starts up for other users, it will quit because it can't read the config file. Multi-user scenarios like the one you describe are not supported, although that's largely for pragmatic reasons rather than by design.

On Windows the chromoting process runs as a service and is therefore always running regardless of who logs in. This is the logical way to allow unattended access in my opinion. I don't see why it couldn't behave the same way on macOS. Could you not run remoting_me2me_host as a system daemon so that it behaves similarly to the Windows counterpart?

On macOS/OS X computers that I maintain there is a local admin account. Most software, including CRD, is initially installed under this account. Once the computer is handed off to the end user another account is created for that user. A lot of times the account creation needs to be done remotely. Then, when troubleshooting remotely it's usually necessary to switch between user accounts. I've always had problems remotely administering Macs because the connection is always dropping any time a login/logout event occurs.

It wasn't until now that I dug deep to figure out why. So no I know and at least there is a workaround - to simply alter the ACL on the CRD config file. I maintain that it would make more sense to have the chromoting process always running to alleviate disconnects and allow access when any user is logged in, just like the Windows version.

Yes, it's definitely possible to improve the way this works, but it's a lot of work and not something we've ever been able to prioritize. On Windows, there's always a process running as Administrator that's responsible for delegating work to another process running as the logged-on user, and this adds a lot of complexity. On Mac, we don't have that process separation--instead there's a single process that quits and is restarted when the user logs in.

Changing the ACL on the config file should allow the host to run as those users, but it's not a very secure solution because that file contains authentication credentials for the user who set up the host.  Those credentials are very tightly scoped to Chromoting, so there isn't a lot that other user could do (basically just add, rename or delete hosts from your account), but it's still not something we'd want to allow by default.