SSH
First connection
Check key permissions, the host fingerprint, username, port, and local network to determine whether the connection fails before or after authentication.
Start connection troubleshooting
Connection, Builds & Diagnostics
Turn Cloud Mac issues into actionable checks
This guide does not start with “try again.” First verify the connection entry point, then check your toolchain, dependencies, signing assets, disk space, and logs. Each step explains what to look for, covering iOS builds, macOS automation, and MLX experiments on OakVPS dedicated physical machines.
For an existing order, log in to the console to submit a ticket. Never send private keys, signing-certificate passwords, or complete payment details on a public page.
Choose by task
Find where the problem occurs
Six entry points cover the main scenarios. If an issue spans multiple stages, start with the earliest abnormal step instead of wiping the entire environment.
XCODE
Xcode build
Verify the active toolchain, project scheme, dependency state, signing files, available disk space, and exportable result package.
View build commands
FASTLANE
Automation pipeline
Separate Ruby, plugin, lane-parameter, and Xcode errors, keeping the complete log instead of capturing only the final line.
Check automation output
TRANSFER
File transfer
Package artifacts and generate checksums before transferring the archive. Avoid moving build directories or dependency caches that are still being written.
View handoff order
SESSION
Remote development session
Confirm that your local network is stable, tasks can continue after disconnection, and interactive sessions and temporary files are cleared before you leave the device.
Check session boundaries
MLX
MLX environment
Check unified memory, model files, isolated environments, and experiment records. Do not judge the environment by speed figures that cannot be reproduced.
Check the experiment environment
First-connection baseline
When SSH fails, check in handshake order
Save the original error first, then change one variable at a time. Changing the username, port, and key together makes the cause impossible to isolate.
Key permissions
Run locally chmod 600 ~/.ssh/oakvps_key. If the private key is readable by other users, the SSH client will reject it before starting authentication.
Host fingerprint
During the first connection, compare the fingerprint shown in the terminal with the connection details in the console before confirming. If host information changes, do not simply delete the old record and skip verification.
Username
Use the system username shown in your order’s connection details. Do not substitute an email address or your local computer username in the remote command.
Port
Pass the port from the connection details explicitly, for example ssh -p 22 user@host. Timeouts usually occur before authentication; permission denials usually occur during authentication.
Network access
Confirm that your company network, VPN, local firewall, and egress policy allow the target port. You can retest on a trusted network, but never transfer project credentials over an untrusted network.
Initial verification
After connecting successfully, first run whoami,sw_vers and df -h, then record the user, system version, and available disk space before importing project files.
Command output clues
Separate connection, build, and automation output
The last terminal line is usually the result, not necessarily the cause. The three command sections below verify connection identity, the Xcode build entry point, and fastlane lane status. Replace the example parameters with your own connection details, workspace, and scheme before running them.
- Connection successfulReturns the remote username, system version, and disk information.
- Build entry point validXcode correctly recognizes the workspace, scheme, and target platform.
- Automation pipeline readableErrors from Bundler, plugins, and the lane retain their full context.
Connection & environment check
$ ssh -i ~/.ssh/oakvps_key -p 22 oak@203.0.113.10
$ whoami
oak
$ sw_vers -productVersion
15.x
$ df -h /Check:If the command returns the remote username, networking and authentication have passed. Investigate system permissions or the project environment next.
Xcode build entry point
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
Xcode 16.x
$ xcodebuild -workspace App.xcworkspace \
-scheme App \
-destination 'generic/platform=iOS' \
build | tee build.logCheck:Confirm the developer directory first, then check the workspace and scheme. Keep build.log; do not copy only the final failure summary.
fastlane output excerpt
$ bundle exec fastlane lanes
$ bundle exec fastlane ios build \
--verbose 2>&1 | tee fastlane.log
[09:24:18]: Driving the lane 'ios build'
[09:24:19]: Resolving package dependenciesCheck:If the lanes are listed, the Ruby dependency entry point is working. If a later step fails, find the earliest error in the log instead of looking only at the exit code.
Build failure diagnosis
Check dependencies in order instead of reinstalling everything
Versions, caches, signing, disk space, and logs affect one another. The sequence below minimizes unrelated changes and helps the next engineer reproduce the same failure.
| Order | Check | Run or record | Criteria |
|---|---|---|---|
| 01 | Xcode version | xcodebuild -version and xcode-select -p |
The toolchain required by the project matches the current active directory; the command line and graphical interface do not point to different versions. |
| 02 | Dependency cache | Record the lockfile first, then check the status of Swift Package, CocoaPods, or project-specific caches. | The lockfile was not changed unintentionally. Clear only caches related to the current error; do not delete all reusable dependencies. |
| 03 | Signing assets | Check the target, bundle identifier, certificate validity, and provisioning-profile mapping. | The assets match the current build target. Passwords and private content do not enter logs, repositories, or ticket attachments. |
| 04 | Disk space | df -h, project-directory size, and DerivedData size. |
Build directories, dependencies, archives, and temporary files have sufficient space; unusually large directories are identified separately. |
| 05 | Complete logs | Use tee to display and save output simultaneously, recording the command, time, and exit code. |
The log contains the earliest error, its context, and the final exit status, allowing another engineer to reproduce it with the same command. |
Compare the lockfile before clearing caches
If dependency resolution changes unexpectedly, first compare lockfile differences before and after the change, package-source settings, and network results. Delete a cache range only after confirming that the cache itself is damaged; otherwise you may turn a reproducible issue into a one-off state.
Separate missing assets from target mismatches
The error may come from an unavailable certificate, a provisioning profile that does not match the bundle identifier, or the wrong build target. Record the error code and target name, but never put certificate passwords, private keys, or complete signing assets in a ticket.
Keep the full context of the first failure
Repeated runs can change caches and temporary files. After the first failure, save the log, command, workspace state, and disk information before testing one variable at a time, so you can tell whether the change actually fixed the issue.
Sessions & artifact handoff
Keep remote sessions and file delivery recoverable
A remote window is only an access point and should not be the sole place where task state is saved. Store commands, logs, artifacts, and checksums in clearly defined directories.
Remote session
Check status once before connecting and once before leaving
- 01Prepare before connecting
Confirm the local network, host fingerprint, target username, and project-file source. Import sensitive files only when the task requires them.
- 02Run long tasks outside the window
Run builds or experiments in a recoverable session manager, and write standard output to a log file at the same time.
- 03Exit before leaving
Confirm that files are saved and task status is recorded, then end the graphical or SSH session. Do not leave unsaved edits in the window.
- 04Revoke access
After a team member leaves or the task ends, revoke keys and access permissions that are no longer needed, and check shared directories.
File handoff
Handle artifacts, logs, and sensitive data separately
- 01Stop writing
Confirm the build has finished before archiving artifacts. Do not transfer directories or database files that are still being generated.
- 02Create a manifest
Record filenames, build version, environment version, generation command, and checksum so the recipient can verify integrity.
- 03Verify the download
Unpack locally and inspect key files. Confirm that the archive is not an empty directory and contains all required logs.
- 04Clean up sensitive files
Following team policy, delete temporary keys, tokens, signing assets, and unneeded model copies while retaining build records that can be made public.
MLX experiment checklist
Record the model, environment, and memory limits before discussing results
MLX uses unified memory on Apple Silicon. Model files, runtime usage, context length, and intermediate results all affect available space. Do not look only at the model-file size or infer environment performance from a single run time.
All three tiers are dedicated physical machines: the Basic tier uses M4, 16GB memory, and 256GB storage; the Advanced tier uses M4, 24GB memory, and 512GB storage; the High Memory tier uses M4 Pro, 64GB memory, and 2TB storage. Choose based on measured usage for your model, dataset, and concurrent tasks.
Isolate the experiment environment
Pin the Python environment and dependency versions for each project, save a reproducible dependency manifest, and do not mix multiple experiment versions in the system environment.
Check model-file size
Record the sizes of the download package, extracted files, cache, and output directory separately. Leave room for temporary files to prevent the experiment from stopping because of insufficient disk space.
Choose the memory tier
Use Activity Monitor or command-line records to capture peak usage. If the system remains under clear memory pressure, reduce concurrency, shrink the workload, or adjust the configuration instead of simply rerunning it.
Keep experiment logs
Record the code version, dependency versions, model identifier, parameters, input summary, output location, and errors so the next run can reproduce the same conditions.
Before submitting a support request
Turn your ticket into a reproducible record
Support needs to know which order, node, step, and time period were affected. The more specific the information, the faster diagnosis can begin.
Order ID
Provide the order ID visible in the console. Do not send payment credentials or complete payment details.
Required
Physical node
State the node used by the order and the current connection entry point to help distinguish the network path from the environment scope.
Required
Time of occurrence
Use a timestamp with its time zone and state whether the issue is continuous, intermittent, or limited to one task.
Required
Reproduction steps
Starting from a normal state, list the commands, parameters, expected result, and actual result in order. Do not omit intermediate actions.
Required
Redacted logs
Attach the complete error context and exit code. Remove private keys, tokens, certificate passwords, repository credentials, and sensitive project content.
RecommendedNeed a Cloud Mac ready for your next task?
Choose Oak M4, Oak M4 Plus, or Oak M4 Pro and rent a dedicated physical machine for the duration of your project. After ordering, view your order, connection details, and support tickets in the console.