Check node status, connection credentials, local network, active sessions, disk space, and task queues layer by layer. Each step provides pass criteria, next actions, and the information to submit—so you do not have to describe an issue as simply “can’t connect” or “it’s laggy.”
Selecting an option takes you directly to the relevant steps. If several issues occur at once, handle “Can’t connect” first, then check performance, builds, or disk space.
No symptom selected yet.
Complete each layer before moving to the next. Do not repeatedly change client parameters while node status is unknown, and do not try to use the same session from multiple devices at once.
Sign in to the console and confirm that the physical node for the order has been delivered and that its name matches the connection details you are using. If the status is still changing, preserve the exact status text shown on the page and do not submit repeated connection requests.
Confirm that the host address, username, and temporary credentials belong to the same order. Do not include leading or trailing spaces when copying. If credentials were just updated, close the old connection window and create a new connection profile.
Temporarily disable local proxies that rewrite routes, then test on both your current network and another trusted network. Record whether name resolution succeeds, whether the TCP connection is established, and whether continuous probes show packet loss—not just a single ping result.
Confirm that no team member is using the same graphical session at the same time. If an old client exited unexpectedly, wait for the session to be released before reconnecting. Rebuild the connection profile only when credentials are correct, the network is reachable, and the old session cannot be recovered.
The figures below show median ICMP round-trip times from fixed broadband probes to each node. They compare network paths and do not represent the actual performance of any specific user network.
| Test origin | Singapore | Japan (Tokyo) | South Korea (Seoul) | Hong Kong | Western United States |
|---|---|---|---|---|---|
| Singapore | 8 ms | 72 ms | 83 ms | 36 ms | 171 ms |
| Japan (Tokyo) | 70 ms | 7 ms | 31 ms | 48 ms | 104 ms |
| South Korea (Seoul) | 82 ms | 32 ms | 6 ms | 43 ms | 126 ms |
| Hong Kong | 35 ms | 47 ms | 42 ms | 6 ms | 148 ms |
| Western United States | 169 ms | 103 ms | 124 ms | 146 ms | 9 ms |
How to read the table:Remote desktops are more sensitive to consistently stable round-trip paths. A path with a lower median but occasional packet loss may feel worse than a slightly higher-median path that remains stable.
Scope and limitations:Probes do not pass through users’ local Wi-Fi, proxies, or corporate egress points. Carrier interconnection, time-of-day congestion, wireless interference, and client load can all change the results. This table is not a performance guarantee.
First determine whether the bottleneck is interaction, CPU, memory, disk, or queue wait. Do not equate a laggy remote display directly with insufficient node compute performance.
sw_vers
uname -m
df -h
vm_stat
system_profiler SPHardwareDataTypeWhen submitting logs, you may include the system version, architecture, volume capacity, and memory status. Remove usernames, sensitive names from project paths, and all access credentials before submitting.
Base SSD capacity depends on the selected configuration: OAM M4 16 has 256GB, OAM M4 24 has 512GB, and OAM M4P 64 has 2TB. Expansion storage should not be mistaken for the base system volume.
In System Information and Disk Utility, verify the device name, connection type, total capacity, and partition status. If the device does not appear at all, record the connection topology and stop repeatedly initializing it.
If the device exists but the volume is not visible, record the file system, volume label, mount point, and error shown by Disk Utility. Do not erase or repartition a device when its data purpose is unknown.
Check which volume actually receives projects, models, build caches, and export files. Insufficient disk space often occurs because caches remain on the system volume while the expansion volume is not yet used as the working directory.
Submit the device list, volume capacity, mount status, first occurrence time, most recent successful operation, and relevant error logs. State whether the task or client was restarted.
Expansion SSDs extend capacity for work data, build caches, model files, or media assets. After identification, confirm the mount point and directory permissions before moving data.
Confirm each device in physical connection order, then verify the link and device tree in system information. When multiple devices fail, test each connection individually to narrow the scope.
Do not send passwords, private keys, recovery codes, complete access tokens, or unsanitized configuration files in the ticket body, screenshots, logs, or email. Support staff do not need these materials to begin troubleshooting.
Order number, node, exact error text, sanitized logs, reproduction steps, occurrence time, client version, and a network-test summary.
Identity secrets other than the username, authorization headers, private-key contents, recovery codes, complete environment variables, and sensitive paths in screenshots.
Submit a ticket without secrets first. Only provide necessary materials within the specified scope after support gives controlled submission instructions.
Complete information does not mean including more content. The goal is to help support identify the objects involved, establish a timeline, reproduce the issue, and assess its scope.
Provide the order number, model, and node shown in the console. Do not provide only a device nickname.
Specify the time zone, first occurrence, most recent reproduction time, and whether the issue is ongoing.
List the actions step by step from a known-good starting point, and identify where the unexpected result first appears.
Paste the exact error text and surrounding context, and state whether the logs came from the client, build tool, or system.
Hide sensitive information before taking screenshots, and state whether the issue affects one task, one user, or the whole team.
List the network, client, reconnection, capacity, and queue checks already completed to avoid duplicate troubleshooting.
Use “node + client + connection stage” as the suggested title. In the body, provide the order number, node, occurrence time, client OS, exact error text, network test results, whether an active session exists, and the reconnection steps already taken.
For remote desktop issues, provide the round-trip median, jitter, packet loss, resolution, and client network type. For build issues, provide the command, commit identifier, start and end times, first error, available disk space, and number of concurrent tasks.
Submitting a ticket through the console links the issue to the order record. If you cannot sign in, contact support@ownamac.com with your work email, order identifier, and issue summary. Do not send passwords or recovery codes.
For active incidents, submit through the console whenever possible so the order and node can be linked. If you cannot sign in, use support@ownamac.com and send only sanitized information.