Community

I’m testing Agent 2.0.1 on macOS for attended support. Agent now launches successfully, but Internet-ID and Password remain “-” indefinitely.

I have ruled out local connectivity: id.remoteutilities.com resolves correctly, and outbound TCP ports 5655 and 443 are reachable. VPN was disabled during testing. Viewer is 2.0.1 and the Agent is the current 2.0.1 download.

Is this a known macOS Agent 2.0.1 issue or a problem with public Internet-ID assignment? Please advise on the next diagnostic step.

Subject: Linux Host 2.0.1 – File Transfer connects but cannot open any directories
I am testing Remote Utilities as a possible replacement for  [censored] on Linux Mint systems and have encountered an issue with File Transfer.
Environment
- Remote Utilities Viewer: 7.8.4.0 on Windows
- Remote Utilities Host: 2.0.1 on Linux
- OS: Linux Mint
- Desktop session: X11
- Linux user: myarboro5886
- User home: /home/myarboro5886
Problem
Remote control works normally.
When I start a File Transfer connection from the Windows Viewer, the File Transfer window opens successfully. The Windows/local filesystem displays normally in the left pane.
The Linux/remote pane, however, is empty. Attempting to navigate or open a directory results in:
Unable to open directory

No Linux directories can be opened or displayed.
Troubleshooting performed
I verified the Linux account and filesystem permissions. The user's home directory and Desktop are owned by the logged-in user and are accessible normally:
/home/myarboro5886
/home/myarboro5886/Desktop

The Host appears to be starting correctly. The main daemon runs as root, while the interactive Host processes are launched under the logged-in Linux user:
root          /usr/bin/r-host -daemon

myarboro5886  /usr/bin/r-host -tray ...
myarboro5886  /usr/bin/r-host -work ...

The Host launches the user processes with what appear to be the correct X11 session variables, including:
DISPLAY=:0
XAUTHORITY=/home/myarboro5886/.Xauthority
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

I also confirmed:
echo $XDG_SESSION_TYPE

returns:
x11

strace testing
I attached strace to the active r-host -work process while reproducing the File Transfer error.
The process successfully accesses:
/home/myarboro5886/.Xauthority

and I did not observe an EACCES or EPERM error involving the user's home directory.
Interestingly, when File Transfer reports Unable to open directory, I did not see r-host attempting to enumerate /home/myarboro5886, /home, /, or another normal filesystem directory.
I did see repeated attempts to access:
/dev/shm/rms_user_config_myarboro5886

which returned:
ENOENT (No such file or directory)

while the global and tray shared-memory objects exist:
/dev/shm/rms_global_host_agent
/dev/shm/rms_user_tray_myarboro5886
/dev/shm/sem.sem_rms_global_host_agent
/dev/shm/sem.sem_rms_user_tray_myarboro5886

I do not know whether the missing rms_user_config_myarboro5886 object is relevant to File Transfer or is simply an optional IPC object.
Core dumps
I also found numerous historical r-host core dumps associated with the LightDM account. However, I performed a controlled test while reproducing the File Transfer problem and no new core dump was generated when File Transfer returned "Unable to open directory."
Therefore, the current File Transfer failure does not appear to be caused by r-host crashing.
Summary
The connection itself succeeds, remote control works, the Linux Host's user-session processes are running under the logged-in user, and normal Linux filesystem permissions appear correct.
The failure appears to occur before Remote Utilities attempts normal directory enumeration.
Since File Transfer support for Linux is included in Host 2.0.1, could you advise whether this is a known issue or whether there are additional logs/debug options I can enable?
I would be happy to provide strace output, process listings, core dump information, or perform additional testing if useful.

Hi Conrad,

Yes—the Agent is not generating an Internet-ID or password. I discovered that in macOS Light Mode, the fields show “-” placeholders. In Dark Mode, those placeholders are invisible because the Agent window’s main area remains white while the text appears to render in a light colour.  
I have attached screenshots from both modes. This appears to be both an Internet-ID assignment issue and a Dark Mode display issue in the macOS Agent.  
Thank you,
Jody