Download Chrome Remote Desktop App For Mac
Dibe Naro
This is the companion extension for the Chrome Remote Desktop website ( ). This extension enables you to install, view, and modify the Chrome Remote Desktop native client from the web UI.Chrome Remote Desktop allows users to remotely access another computer through Chrome browser or a Chromebook. Computers can be made available on an short-term basis for scenarios such as ad hoc remote support, or on a more long-term basis for remote access to your applications and files. All connections are fully secured.Chrome Remote Desktop is fully cross-platform. Provide remote assistance to Windows, Mac and Linux users, or access your Windows and Mac desktops at any time, all from the Chrome browser on virtually any device, including Chromebooks.For information about privacy, please see the Google Privacy Policy and the Chrome Privacy Notice.For help or troubleshooting please click here:
Howerver, starting a remote desktiop session only result with a blank screen. I have tried searching for a solution, but none of them are up-to-date, or gives a helpful hint for a solution. I also tried gnome-session-classic, but without luck, too.
This answer originates from Rob Calistri's comment in François Beaufort's G+ post. Due credit to the source. If you've updated Ubuntu (or Ubuntu Gnome) recently, instead of a blank screen, you likely see just wallpaper without any panels when connecting via Chrome Remote Desktop. This modification forces Chrome Remote Desktop to use the existing X Server instead of creating new desktops.
The chrome-remote-desktop application works just fine with linux generally and Ubuntu specifically. It however does NOT play nice with LightDM and Unity. Ubuntu Bug #1274013, and the related bug in comment #3 shed some light on this: gnome-session is broken without 3d acceleration.
I've only ever used it for that use case - to connect to OSX / Windows boxes from my Ubuntu work laptop. In those instances, the viewer is just accessed by installing via the chrome extension located here: -remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp?hl=en
EDIT: Since the remote-desktop host feature is currently in beta, it's not accessible in the chrome-stable installation, which is why I've not seen it listed and there is no option to enable remote connections in the stable installation, as far as I can tell.
Create a file called .chrome-remote-desktop-session in your home directory. This should be a shell script that starts your preferred desktop environment. Find the correct command to start the desktop by looking in /usr/share/xsessions/ for the desktop entry.
Tip: Your desktop environment may not support more than one session at a time. In this case, we recommend that you use different desktop environments for your Chrome Remote Desktop session and your local session, or use the session chooser.
If you use the session chooser, we recommend that you sign out of the desktop environment in Chrome Remote Desktop or your local session before you sign in to the same desktop environment on the other.
Concretely, let's say you want to map your local (Windows) Ctrl key to the remote (Mac) Cmd key. From the table above we see that the code for the (left) Ctrl key is "ControlLeft", while the code for the Cmd key is "MetaLeft", so from the "Configure Key Mappings" dialog:
At this point you should be able to use Ctrl-C, Ctrl-V etc. on your local PC to trigger the corresponding Cmd-C, Cmd-V etc. commands in the remote Mac. The solution works quite well for me and it resolves a perennial problem of how to use the Cmd button while on a Windows PC without having to rely on external apps or plugins.
I have confirmed, using chrome remote desktop, that search+another_key does the same as CMD+another_key while remote-connected to my mac-book pro over home WiFi. I also noted that if I want to enter two search+another_key presses sequentially, I must release and repress the search key after each instance
i have a PA VM-200. I've used the built-in 'chrome-remote-desktop' protocol, and doesn't work. The description seems to say this protocol is in BETA and is for the support function fo the chrome-remote-desktop.
But i'm guessing it's similar to TeamViewer where client connects to central server? In that case TCP connection goes only from client to internet server, but later desktop sharing can work in both ways. So you can't block TeamViewer only in one direction.
Since you want to remotely connect outside your network using Chrome Remote Desktop, then it seems that there is no need to configure LAN WAN Inbound Rules. However, you might need it if ever there will come a time that you want to remotely connect to your network from outside using Chrome Remote Desktop.
I tried to install the google remote desktop on the jetson nano and xavier. [url] [/url] Was someone successful with this? I can control my Win10 machine with the nano, but cant install/download the packages.
(Cross posting her from the desktop mailing list since a helpful community member mentioned that people are not active on mailing list. Also, another member mentioned that there is a non-interactive/password driven option already - feel free to provide pointers for it, if that is the case.)
I am looking into supporting CRD for GNOME/wayland. CRD would be leveraging remote desktop APIs (along with screencast) as exposed by xdg-desktop-portal,-gnome. While experimenting with remote desktop APIs, I see that for enhanced security, an interactive dialog (relevant code: -desktop-portal-gnome/-/blob/main/src/screencast.c#L345-349) is always presented to the user to select sources/devices they want to allow to be remote controlled. Though this workflow would make perfect sense when a user is directly connected to the machine and is allowing someone remote to take control (e.g. to get help from IT) but it is less than ideal for a user who is trying to access their own machine remotely (e.g. accessing their work computer from home).
Looking at how other software/systems are supporting screen capture/remote desktop, we see wlroots/sway allows for configuring the output screen to capture in a config file. I believe Windows.Graphics.Capture APIs can also allow Win32 apps to capture a window/screen without user interaction.
Right now, there is no complete story of how actual remote login should work, in contrast to what you have discovered already works rather well: sharing your screen. The main reason for this is that the problems they introduce that needs solving are fundamentally different, and the needed solutions will likely be different too.
Continuing a session remotely must without doubt make sure that the physical session is not unlocked or turned on. Logging into your machine at the office from home should not allow colleagues in the office see what you are doing.
This would mean a user session would contain a running GNOME session, using mutters headless mode in which it will not attempt to interact with input devices or monitors. The only way a user would interact with it is via a remote desktop service. The session would launched on boot, or manually via Cockpit/ssh or something similar.
This would mean a user logged in to a machine physically, later locked it, and while the session was locked, logged in remotely. When logged in remotely, the display server would swich mode to fully headless, making sure input and output devices would not be interacted with. Implementing support in the display server to toggle between being headless and headfull is probably not very difficult, but needs to be done.
This is a different type of problems than the other two; it would need a remote desktop service running on the system level that can take care of user selection, logging in, session launching, as well as handing over remote desktop connection to user sessions. I imagine this either needs integration with the gdm greeter, or logind itself, depending on how a login screen should work. As for how it would work past the login phase, I imagine it would be more or less the same as step 2 or step 1, depending on whether physical access would be needed.
That sounds reasonable. Thanks for the details around it and the intricacies involved. IIUC, #2 will allow the user to continue the remote session from where they left off in physical session (and vice versa)?
I introduced mx67 to the company.
Recently, I found that I control internal devices from outside using Chrome remote desktop.
I want to know how to prevent Chrome remote desktop from working in mx67.
3. Here comes the problem. I tried to go to the root in the remote desktop, but VM asked for a password. I have no idea what this password comes from, and I tried the instance id and my gmail password, not working. (figure shows the remote desktop)
So I'm having an issue with Google Chrome Remote Desktop and Intel Iris Xe Graphics. I'm able to remote into my laptop, however, if my laptop lid is closed, the start menu or windows won't populate. If my laptop lid is open, everything works fine.
The only way to get around my laptop lid being closed and chrome remote desktop working perfectly fine, is if I go into Device Manager, and disable Intel Iris Xe Graphics under Display adapters. Is intel aware of this issue? Thanks.
4. It never worked with the laptop lid closed, only when the laptop lid is open, remote access works perfectly fine. The only way to get remote access to work is if I disable Intel Iris Xe Graphics under Displlay adapters in Device Manager.
Hello, I'd like to use chrome Remote Desktop to access my computer both locally and remotely. When I click on enable access which has worked for machines prior to install bitdefender it fails. It looks like it uses different ports than traditional rdp is there a way to allow connections? Thanks!