Access and disk checks

Start with the delivery record before connecting

Before setting up file storage or backups, confirm the address, operating system, and directly attached drives. Once the server is delivered, find its IP address and login credentials in the server details in the control panel.

Check the delivery record in OnuCloud View OnuCloud access instructions

A payment record does not confirm delivery. Once the server is ready, connect using the details shown in its record.

Linux family
SSH
Windows Server
RDP
Remote management
First IPv4
Check first, then connect

Start with the delivery record

Payment, server preparation, and remote login are separate steps. Before connecting, rely on the server status shown in the control panel. Do not infer the address from the order name or reuse credentials saved for another server.

  1. 01

    Identify the correct server

    Sign in to the OnuCloud control panel, open the server details for the relevant order, and check the memory tier and selected operating system. When managing multiple servers, confirm that the details match the server being worked on before copying connection information. This helps prevent backup or disk operations from being run on the wrong machine.

  2. 02

    Check all connection details

    Find the IP address, login account, password, and any other connection details provided in the server record. Do not guess the port or username based on common defaults. This guide does not provide a generic account or fixed port; use the details supplied with the server.

  3. 03

    Choose a client for the operating system

    Use SSH for Linux, FreeBSD, and Proxmox VE; use RDP for Windows Server. Check any old addresses, accounts, and saved passwords in the client. If delivery is not yet complete, check the server status rather than repeatedly trying unconfirmed settings.

Do not share login passwords, private keys, or complete credentials in public screenshots, command history, or ordinary email. When troubleshooting, retain the error message and redact sensitive details from any screenshots.

Linux and Unix-like systems

Verify the host before changing SSH authentication

AlmaLinux, CentOS Stream, Debian, Ubuntu Server, FreeBSD, and Proxmox VE are accessed over SSH. System administration varies by operating system, but connection details always come from the same delivery record.

Make the first connection

In a local SSH client, enter the first IPv4 address, the account provided with the server, and the actual port. Then sign in using the authentication method listed in the server details. If prompted to verify the host identity on the first connection, check that it matches the intended server and its available identity information. Do not treat acceptance as a routine step to skip.

If the same address was previously used for another operating system, the client may report a host identity change. First confirm whether the server was reinstalled or the connection target changed. Then update the locally saved record; do not dismiss the identity check just to clear the warning.

Test new authentication before closing the old session

After the first login, consider changing the login password and configuring SSH keys according to the selected operating system's account and permission rules. Keep the private key on the management system and add the public key to the target account's authorized keys. Do not confuse public and private keys.

Keep the current session open while changing authentication or firewall settings, and test the new configuration in a second SSH session. Once the new session works, close the original connection. This helps prevent a configuration change from cutting off every management route.

Linux disk-check commands do not apply directly to FreeBSD. SSH provides access; storage and permission tasks must still follow the tools and rules of each operating system.

Windows Server

Sign in to RDP with the account in the delivery record

Connect to a Windows Server machine using Remote Desktop Protocol (RDP). Open a local Remote Desktop client and start a session using the first IPv4 address and login credentials shown in the control panel. Do not reuse saved credentials for another server.

  1. 01

    Check the target and account

    Check the computer address, account field, and actual connection settings in the client, especially any previously entered account. Verify certificate or identity prompts against the delivery record. Remote Desktop does not remove the need to confirm the target.

  2. 02

    Check your input and system settings

    If the password is rejected, first check the keyboard layout, capitalization, and any spaces included when copying and pasting. Windows Server may use English, Traditional Chinese, or Simplified Chinese as its system language. The interface language does not change the delivered account or the rule to connect using the first IPv4 address.

  3. 03

    Keep a recovery path available

    Once signed in, adjust account policies, Remote Desktop permissions, and firewall settings as needed. Test each change in a new session. Disconnecting the client does not back up data; check important files and service status separately.

Address roles

Use the first IPv4 address for remote management

When a server has multiple IPv4 addresses, use the first address in the list for SSH or RDP. Other addresses are for services or virtual machine planning within the operating system. Their presence in the delivery record does not make them remote management login addresses.

Assign address roles before configuring the operating system and binding services.
Address roleUseCheck before use
First IPv4SSH or RDP remote managementMatch it exactly to the server details and use that server's account and authentication information.
Other IPv4 addressesBind to services or virtual machines within the operating systemCheck address allocation, network configuration, and service listening settings to avoid duplicate bindings.

Changing host networking or virtual machine address allocation is a system configuration task. Record the current working settings and verify changes one at a time. Avoid changing the management address, routes, and authentication method simultaneously so the cause of any connection change remains clear.

Storage checklist for first login

Two independent NVMe drives: identify before creating a pool

AMD physical servers include 2 × 1TB NVMe drives, each directly attached, with no hardware RAID. Being able to log in only confirms that the management connection works. Before setting up file storage, also check the drives, system usage, and intended redundancy model.

Record each drive and its intended use

Record each drive's identifier, capacity, existing partitions, and mount points. Distinguish the system drive from the drive intended for data. If additional drives have been selected, list them separately; do not infer physical drive locations from device enumeration order.

The following Linux commands only read block device and filesystem information. They do not create an array or format drives. Use the actual device names shown in the output. On FreeBSD, use the system's own device and storage inspection tools.

Linux · read-only checks

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
findmnt

Review the output before choosing a target. If the purpose of a device is unclear, do not run commands to erase, partition, or create a storage pool.

Separate use: capacity and failure domains

The two 1TB drives have a combined nominal raw capacity of 2TB, but this is not the same as usable filesystem space. Partitions, system usage, and formatting all affect available capacity. Data on one drive is not automatically copied to the other.

This setup suits plans that assign different purposes to each drive. Two drives alone do not provide redundancy.

Mirroring: plan redundancy and backups separately

With two 1TB drives in a ZFS mirror or software mirror, plan for nominal capacity of about half the combined capacity. Actual usable space is also affected by system and filesystem overhead. Confirm where the data will go before creating the pool, and transfer any data from existing partitions first.

Mirroring helps protect against a single drive failure. It does not replace a recovery copy for accidental deletion, overwrites, or system issues. Off-site backups must be configured separately.

Once storage is ready, configure backup jobs by specifying the source directory, destination, retention policy, and authentication method. Start with a small transfer and test recovery. A completed job does not prove that files can be restored; retrieve sample files and check their contents and permissions.

Troubleshoot by layer

When a connection fails, check the address, authentication, and network

Timeouts, connection refusals, and authentication failures point to different issues. Keep the original client error and work through the checks below. This is more effective than repeatedly changing passwords and firewall settings.

  1. 01

    Check delivery status and the first address

    Reopen the server details and confirm the target machine, operating system, and current status. Check whether an additional IPv4 address was used by mistake or whether the client still has an old server address saved. Do not assume a connection failure is an operating system issue until delivery is confirmed.

  2. 02

    Distinguish authentication errors from connection failures

    For an authentication failure, check the account, authentication method, password input, and matching key pair. For a timeout or connection refusal, record the error before changing account policies. These symptoms can also be related to the network path or system service rules.

  3. 03

    Check network rules at both ends

    Check the local network, outbound restrictions, and client settings, then review the server firewall and relevant SSH or RDP service rules. An address failing to respond to one type of probe does not, by itself, prove that remote login is unavailable. Check the result in the actual client as well.

  4. 04

    Include reproducible details in a support ticket

    If the connection still fails, sign in to the control panel and submit a support ticket. Include the order ID, operating system, protocol, exact error message, time of the issue, and any configuration changes made beforehand. Note whether the connection has worked before and which checks are complete. Do not paste full passwords or private keys into the ticket.

Submit an access troubleshooting ticket to OnuCloud
Recovering from configuration errors

Emergency access is not a replacement for routine remote management

If a system network or authentication setting is misconfigured, the browser-based graphical session in the control panel is for emergency recovery only. It is not a public connection method; continue using SSH or RDP for routine management.

Start recovery by reviewing recent firewall, network, or account changes. Avoid reinstalling the system when data status is uncertain. If assistance is needed, describe the steps taken in a control panel support ticket. Before reinstalling, handle any data that needs to be kept; a reinstall is not a non-destructive troubleshooting step.

DGX Spark access

Use SSH to manage DGX OS

DGX Spark delivery credentials are also available in the OnuCloud control panel. Open the relevant server details, check the address and account information, and connect to DGX OS over SSH. Do not apply the operating system or disk planning instructions for AMD physical servers.

Use the details for this machine

Use the address and authentication details shown in the server record; do not guess default accounts or ports. After the first login, verify the SSH session and account permissions before changing keys or firewall settings. Keep the original session open and test the updated authentication settings in a new connection.

Prepare the model and application environment after access is confirmed. An SSH login does not verify application dependencies; environment configuration and business data remain the server administrator's responsibility.

Request hard reboots and reinstalls by ticket

DGX Spark does not include BMC / IPMI. To request a hard reboot or system reinstall, submit a ticket in the control panel with the machine ID, observed issue, and steps already taken. Do not try to use out-of-band management procedures intended for another type of device.

Before requesting a reinstall, transfer any files that need to be kept and confirm the target machine. Do not treat environment recovery and data retention as the same task.

Read the OnuCloud DGX Spark overview

Continue with the correct server record

For a delivered server, first check its details and credentials. For storage that is still being planned, decide on drive assignments and redundancy before configuring it.

Open OnuCloud server details Configure an OnuCloud physical server