Remote Access Frequently Asked Questions

How can I gain the remote access to GM/CA @ APS computers?

The remote access needs to be requested when applying for beamtime. There is a checkmark in the user account setup utility that enables remote access after the beamtime is granted. You will also need to specify the IP domain(s) from which you are planning to login. Keep in mind that many institutional networks are behind the firewalls. Please use the "Show my IP" tool to find out how your IP is exposed to us. As a security protection, we only open our computers to requested IP domains, but you may specify multiple domains.

What network speed should I have in order to be able to collect data remotely?

Please read the Speed Benchmarking page.

Can I improve my connection speed?

It may be possible to improve the speed by tuning the TCP parameters on your computer, although the administrative access to your computer and some computer administrating skills may be required. Please read the fasterdata.es.net guide.

How long can I use the remote access capability?

The NOMACHINE™ remote access is provided to two beamline computers ('acquisition' and 'processing') during allocated beamtime and solely for collecting and analyzing data in parallel. These computers can also be accessed by SSH/SFTP, but it is not recommended since may affect your data acquisition and processing speeds. Additionally, the NOMACHINE™ and SSH access is provided to our second-day-area computer for two more days solely for backing up data. The remote access resources are mapped in the following table:

Computer	Primary Purpose	Primary Access	Other Access	Availability
blXws2	Acquisition	NOMACHINE™	SFTP/SCP	Day 1
blXws6	Processing	NOMACHINE™	SFTP/SCP	Day 1
blXws5	Backup	Globus GridFTP, bbcp, FDT, SFTP/SCP	NOMACHINE™	Days 1-3

Here X=1 for 23ID-D and X=2 for 23ID-B. The full URLs are blXwsN.gmca-aps.anl.gov.

Please request additional SCP/SFTP connection details from your host or see the SCP/SFTP information below.

Can I have an extended or permanent remote access?

Long-term remote access to GM/CA @ APS systems is not provided. The major consideration behind such policy is to prevent overloading our systems, which may slow down data collection or processing for the groups doing experiments during their allocated beamtime.

Why do I have to login on different systems for 23ID-D and 23ID-B?

The two beamlines have independent computing systems with different NX™ servers, different account management, and different subnets.

What types of operating systems can I use for remote access?

Supported platforms are MacOS, Windows, and Linux. Check the NOMACHINE™ (NX) web site for additional details. NOMACHINE players may also work on Android and IOS devices, but the screen size and resolution may likely be insufficient for controlling experiment with JBluIce.

What are the requirements to hardware?

Network connectivity must be ADSL or faster. Minimum video resolution is 1280x1024, but 1600x1200 or higher is strongly recommended.

Are dual monitors supported?

Yes, but with some restrictions: both monitors should be set to the same color depth. See the NOMACHINE™ article for additional details.

What are my connection options?

GM/CA@APS uses the NOMACHINE™ NX technology to provide users with full remote desktop experience almost like being onsite. There are three NX connection options, each having its cons and pros depending on your network connection, client computer CPU, GPU, RAM, and etc. These options are summarized in the table below and you can choose either one based on your preference. Sometimes you may need to experiment in order to see which option works for you best.

Option	NXplayer	Webplayer: Chrome & Edge	Webplayer: Firefox & Safari
Installation required?	Yes, installation and updates. See below.	No, if you have the browser installed	No
Desktop transfer technology	X11 Vector graphics	x264 video stream via WebRTC	Motion JPEG (MJPEG) video stream
Desktop transfer efficiency (speed)	Efficient (low network Mb/s requirement)	Efficient, but needs fast client CPU to uncompress x264	Slower, whether it is acceptable depends on your network speed
Desktop transfer reliability	Best	Weak (may pixelate for some users)	Moderate (may pixelate for few users)
Fitting hires desktop on lowres screen	No	Yes (see below)	Yes (see below)

If you are OK with installing and periodically updating NX Player on your computer, perhaps that will be your best option in terms of connection speed (lowest lag in the remote desktop response) and reliability (lowest chance of pixelation or dropped connection). Using NX Webplayer is the easiest and if you run it in Chrome to take advantage of WebRTC, it may be equally fast, but some users report problems with it. The matter is that the Webplayer technology adds an extra layer of communication on top of NX Player (it uses NX Player internally) which needs more computer resources and introduces more parameters (e.g. the browser brand and version) to optimize for best experience. Using NX Webplaer without WebRTC may be more reliable, but slower and then it depends on your network speed if the response is acceptable. Please always use wired network connection instead of Wifi when running any version of NX software.

Do I need to install any software in order to connect remotely?

The simplest connection option is to use NX WebPlayer. The later runs as a web page in regular web browsers. No browser plugins/extensions or Java is required. Therefore with the WebPlayer option you do not need to install any software; just make sure your browser does not use any Javascript blocker like NOSCRIPT or the blocker whitelists the GMCA website. Start the WebPlayer here.

Can I install a standalone NxPlayer application instead of WebPlayer?

Installation of NxPlayer is completely feasible, although it requires a few extra steps compared to using the NOMACHINE™ WebPlayer.

If you have admin rights to your computer, download and install the NOMACHINE™ Enterprise player for your operating system from the NOMACHINE website; then start the nplayer.
If you do not have admin rights to your computer and you are on Windows, you can still download the NOMACHINE™ Enterprise player: it will install for non-admin users too.
Once you start the standalone NxPlayer, click on the "Open connection" button.
Load the preconfigured NX session file saved from Table-2.

WebPlayer is slower for me than NXplayer. Can it be improved?

WebPlayer and regular NXplayer (desktop application) use different ways of transferring remote desktop graphics to your computer screen and WebPlayer itself also deploys different ways depending on your web browser. NXplayer tries to use vector graphics whenever possible, which is very efficient as long as you do not have too many images or video on your desktop. In its turn, WebPlayer defaults to Motion JPEG (MJPEG) which as a stream of JPEG snapshots of remote desktop. However, with some browsers, e.g. Google Chrome it can use very efficient x264 video compression (or sometimes VP8) via the WebRTC streaming protocol. Then WebPlayer can be fast. WebRTC will not work in Safari or Firefox. It may work in Google Chrome, or Microsoft Edge, or Opera depending on the browser version. Since web browsers as well as NOMACHINE software are in permanent development, it is hard to predict compatibility in advance. For example, WebRTC worked with Google Chrome version 88, but stopped working with version 89. When WebRTC "does not work", remote desktop does not load after you login with WebPlayer. Given this unpredictability, we decided not offering WebRTC by default. There is a link to WebRTC sessions in Table-1 in case you want to try it on your own risk. You can see this link for Google Chrome, Microsoft Edge, and Opera browsers only. The difference between Classic (MJPEG) and WebRTC (x264) links looks as follows.

Classic (MJPEG):
https://xxx.gmca.aps.anl.gov:4443/nxwebplayer?config=gmca_classic.nxs

WebRTC (x264):
https://xxx.gmca.aps.anl.gov:4443/nxwebplayer?config=gmca_webrtc.nxs

If WebRTC connection fails for you either with remote desktop never loading of with an error message like this:

then replace in the URL "webrtc" by "classic" and try connecting again. It may be a bit slower, but should work. Classic connection was the only one used before April 2019.

WebPlayer login wheel is spinning forever, what is wrong?

In some cases WebPlayer may stuck on login after reporting "Creating desktop". You may see a spinning wheel and no remote desktop with Argonne Security dialog. It is a reported bug and NOMACHINE is working on it. Try to resize the browser window 1-2 times. In most cases it helps.

WebPlayer desktop pixelates or mouse cursor is invisible on some windows. What can I do?

Unfortunately, WebPlayer is not free of bugs and its behavior depends on type of web browser, client (user) operating system and even client's computer hardware (CPU, graphic processor, network card), which makes it hard to resolve with the NOMACHINE Support. For example, even locally at GMCA it may pixelate the desktop for some client computers (see a screenshot below) and work perfectly for others.

Pixelation can be cleared by moving affected window, but if it happens too often and disrupts your work, try switching to NX Classic connection, changing web browser or installing NX client.

Can I increase resolution in WebPlayer?

Yes, unlike NXplayer, WebPlayer allows you to see remote desktop in a higher "resolution" than the resolution of your desktop screen. It is possible because remote desktop is transferred as an image and it can zoomed out. Go to View controls of your web browser and apply "Zoom Out".

I am having problem to start standalone NxPlayer.

This may happen sometimes because of the NxPlayer cache left after your previous beamtime. The NX™ Enterprise player may be automatically updated when new releases become available and the cache corresponding to an older version may become incompatible. The recipe is to wipe the cache by deleting the .nx directory. If your computer is Unix/Linux or Mac, the .nx directory is located under your home directory. On Windows it is under "C:\Users\<username>".
If you downloaded a 32-bit portable version of NxPlayer for Linux, be aware that some recent versions of Linux (namely Ubuntu of Fedora) may not have support for 32-bit applications. To check if it is your case, open a terminal, find nxplayer and try to run it as "./nxplayer". When no 32-bit support is available, you will see the message "no such file or directory", although the file exists. In this case download the 64-bit portable NxPlayer.

When I am trying to login, the NxPlayer keeps telling me "Authentication failed".

Perhaps there was a miscommunication with your host about remote access or you are trying to login from a computer, which IP does not match the IP range you provided to us (see the "Show my IP" tool), or you are trying to login too early (your beamtime has not started) or too late (your beamtime is ended), or you are trying to login to incorrect beamline (e.g. 23ID-B instead of 23ID-D or vice versa). In any case please STOP and contact your host. If your login attempts fail too many times, the ANL automatic protection system may treat you as a hacker and automatically ban your IP, which will make the issue much harder to resolve. The same applies to unsuccessful SSH and SFTP logins: do not try more than three times; instead contact your host. You can also run Check Credentials tool which will let you check your password, eligibility of your IP address and the dates when you are allowed to login.

My connection was blocked, but I swear that I did not try to login many times. What did I do wrong?

There is a possibility that NxPlayer tried to login on its own. It may happen if you checked a box for saving passwords. Then, the NxPlayer may repeatedly try to log you in. If you saved an incorrect password or if you are trying to login beyond your beamtime time slot, the rejected logins may lead to a firewall block. Please do NOT check the NxPlayer box for saving passwords!

When I am trying to login, the session is terminated before I get any connection.

This is most likely a corrupted cache or cache from an older NX version either on a client or server side. See instructions above on cleaning cache at your side. To clean cache at the server side, either ask your host or ssh to respective GM/CA @ APS computer and type:
rm -Rf .nx
Try again after the cache is deleted.

I login to my desktop and some panels are missing or applications not working. What happened?

This is known to happen when users login locally and remotely on the same computer at the same time. Since both the applications started by local and remote users write their auxiliary files into the same places, they may overwrite each other's records causing the conflict. The recipe is not using the same computers for remote and local logins with the same username. For example, if the remote part of the group logins on workstation-2, the local part is advised to use workstation-3.

How to end the NX™ session properly?

- To close all of your programs properly, you should use session logout as shown in the illustration below.

A common mistake is to click on the cross at the top of NX™ window. That gives two options: "Disconnect" and "Terminate".

Terminating is OK since it has the same effect as logout. Disconnecting leaves the session and all programs inside it running at the GM/CA @ APS computer. We shall have to kill them after your beamtime is ended and it may result in corrupting files opened by the applications.

Are there any other known problems?

- If Windows computer has Cygwin installed and the cygwin.dll is in the system path, that may cause a conflict with NX™ client installation. Upgrading cygwin and NX™ to their latest versions usually fixes the problem. Alternatively, remove the cygwin directories from the system path.

Are there any alternatives to NX™?

- You may try VNC tunneled via ssh. You will need some SSH client and a VNC client (e.g. UltraVNC, TightVNC, RealVNC, or TigerVNC). First, create an SSH tunnel for VNC:

ssh -L 5950:localhost:5950 [email protected]

where the GM/CA workstations names are explained on the remote web page; then run VNC on your remote computer and login with your account:

vncviewer localhost:5950

NOTE: do not replace "localhost" by anything else.

How can I start/use Pilatus or Eiger software when I am remote?

- Indeed, Pilatus software runs on a separate computer. Pilatus and Eiger servers have no graphical interface and you do not need to see an output of them. Simply click on the detector icon in the panel area at the top of the screen:

and make sure a new minimized terminal window has opened.

Coot or Pymol fail to start in NX session. What is wrong?

- Coot and Pymol use OpenGL capability of X11 provided by the graphics driver. Depending on the computer where the NX™ client is running, this capability may or may not be supported. If this happens, try to set the LIBGL_ALWAYS_INDIRECT environment:

export LIBGL_ALWAYS_INDIRECT=1

Then try to start Coot or Pymol again from the same terminal window. Please note that remote performance of OpenGL may be sluggish.

How can I offload my data?

- You need to use either Globus Online, or SCP/SFTP, or bbcp, or FDT. Among these tools, Globus Online, bbcp, and FDT may be 2-3 times faster than SCP/SFTP for bulk transfers, but they may suffer from firewall blockages as they use multiple TCP ports. If you face such blockage, you need to either resolve it with network administrator at your institution or revert to more conservative SCP/SFTP that uses standard port 22.
Globus Online is basically a gridFTP service with a convenient web browser interface developed by several US research institutions including Argonne. It is between 2x and 3x faster than SCP, which is a considerable advantage for transferring large amounts of data in spite of one-time effort to setup and limited sync capability (support for continuous sync is in progress). If you are interested in this free service, please check the details in our Globus Online User Guide.
Unlike Globus, bbcp and FDT do not require creating any additional accounts while being equally fast. However, they do not have rsync capability and the command line syntax is somewhat cumbersome.
All data transfers use a dedicated workstation blXws5 (X=1 for 23ID-D and X=2 for 23ID-B). It is accessible from declared IP domains during your beamtime and for two extra days after the beamtime is ended. In principle, blXws6 may also be used for SCP/SFTP only, but the primary task of that workstation is data processing and then it is only available during beamtime. You may use any SCP/SFTP client available for your platform and supporting SSH2, but it is preferred to deploy those clients that preserve files time stamps. Among command line clients, rsync and openssh are perhaps the most commonly used. Both are included with Linux and MacOS while on Windows they are available with Cygwin. The command lines for transferring data with rsync and openssh will look like this (these should be executed on a computer in your lab):

rsync -avz -e ssh [email protected]:/remote/dir /my/local/dir/

scp -rp [email protected]:/remote/dir /my/local/dir/

Among SCP/SFTP clients with friendly graphical user interface you may try (listing these clients here does not mean our endorsement):

Multiplatform: FileZilla.
Linux: GFTP.
MacOS: Fugu, CyberDuck.
Windows: WinSCP.

Keep in mind that SCP works faster than SFTP, but in general SFTP/SCP are not very fast data transfer protocols. In some cases shipping an external hard drive along with your samples might be a better option.

How can I learn more about GM/CA @ APS remote access?

Study our Remote Operations Manual for Users. Also, check our remote access video demo (please turn on the sound!).