I'm connecting to my remote server running Xubuntu. When I log in directly to the box, all is fine - the problem appears when I connect using Chrome Remote Desktop. If I try and do anything important (e.g restart, change networks, install software) through the GUI I get a permissions error. For example trying to enable my OpenVPN connection returns:

VPN Connection Failed Not authorized to control networking

In terminal, it seems I'm logged in as my usual user. But I can't reboot (can't remember if this normally requires sudo - changing networks certainly doesn't):

foo@bar:~$ reboot
reboot: Need to be root

As soon as I sudo I can do anything through the command line - but this doesn't do me any good for all the stuff in the GUI I'd like to be able to do remotely.

I tried adding my user to netdev, but that didn't solve the problem:

foo@bar:~$ groups foo adm cdrom sudo dip plugdev netdev lpadmin sambashare chrome-remote-desktop

My theory is that I'm not actually logged in as my user, or that the GUI at least is being triggered by another user that doesn't have proper permissions.

  1. How can I find out what "user" has triggered the xfce session I'm in?

  2. How can I give that user appropriate permissions? I know it's poor practice to add non-root users to root but I'm tempted ;)

Looked for a chrome-remote-desktop user but that doesn't seem to exist - although there is a group by that name:

foo@bar:~$ grep 'chrome-remote-desktop' /etc/group


Any ideas? Thanks in advance!


This happens because of the way Chrome Remote Desktop works. It creates a new session which you can access remotely in parallel to the other sessions. Normally the X server/GUI runs on session 7 (you can try and change sessions with Ctrl + Alt + Fn, where n is the session number), and Chrome Remote Desktop uses a different one. So whenever you're asked to enter your password using a GUI, the window appears on the main GUI session (session 7), and there's no way to access it from Chrome Remote Desktop directly.

Fortunately, there's a bit of hacking you can do to circumvent this. As mentioned here, you could edit /opt/google/chrome-remote-desktop/chrome-remote-desktop (create a backup of this file first in case anything goes wrong):

FIRST_X_DISPLAY_NUMBER = 0 # Replace 20 by 0

Then comment out the while loop:

def get_unused_display_number():
    """Return a candidate display number for which there is currently no
    X Server lock file"""
    # while os.path.exists(X_LOCK_FILE_TEMPLATE % display):
    # display += 1
    return display

Another solution is to run applications from terminal with sudo, e.g. sudo google-chrome (not recommended).

Hopefully the team developing Chrome Remote Desktop will hear us all out and soon change this behaviour.

  • Thanks for the info! +1. Your answer would be improved if you were to summarize the actions recommended at your Google Product Forums link, though. – hBy2Py Mar 6 '16 at 20:53
  • Thank you for the comment, Brian. I didn't summarise the actions because they're well described on the linked web page and I thought that wouldn't be necessary. – Rafael Mar 6 '16 at 23:31
  • True. Though, what happens if Google decides next year to toss Product Forums into the circular file? Your answer then gets its key content amputated. Providing at least a quotation of key content from links, in order to avoid this happening, is actually part of the site guidelines for answering questions: "Always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline." I stumbled over this at first, too. – hBy2Py Mar 7 '16 at 17:36
  • @Brian, that's a very good point. I've edited the answer accordingly. Thanks! :) – Rafael Mar 7 '16 at 20:26
  • <thumbs-up> Welcome to SuperUser! :-) – hBy2Py Mar 7 '16 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.