Troubleshooting

Start with the smallest safe check, then make one change at a time. Do not include credentials, private keys, full access tokens, or sensitive data paths in diagnostics or support requests.

Access denied or expired CLI login

Confirm the TU/e account, selected project, role, EduVPN state, and current interactive login. If the project is absent, ask the project owner to verify membership rather than repeatedly retrying.

Run:ai CLI reports an x509 certificate error

An error such as x509: certificate signed by unknown authority means the Linux trust store used by the CLI cannot validate the certificate chain. It is not normally fixed by changing your Run:ai password.

1. Check that the computer’s date, time, and time zone are correct.
2. Connect eduVPN when it is required for your location and retry once.
3. Run runai version and record the CLI version and Linux distribution.
4. If the CLI came from an older download, reinstall it through the current Run:ai Help → Researcher Command Line Interface flow described in Install and verify the command-line tools.
5. If the error remains, stop and send the SCC AI Engineer the exact error, operating system, CLI version, time, and hostname being contacted.

Do not use an insecure TLS flag, disable certificate verification, or download and install the website’s leaf certificate as a new root certificate. On a managed or security-hardened Linux system, the correct institutional CA update must come from SCC or your local IT administrator.

Podman login, image push, or image pull failure

Confirm the exact Harbor project and immutable image tag. Refresh the interactive registry login, then retry. For a pull failure, compare the workload image path with the tag visible in Harbor and confirm project access.

Workload stays pending or reports insufficient quota

Inspect the selected project, compute-resource preset, priority, and requested GPU amount. Projects normally use over-quota capacity, which has no guaranteed start time and may be preempted. When several projects compete for that capacity, scheduler fairness is proportional to configured project GPU quota; it is not equal weighting. Reduce a test workload to the smallest suitable preset or wait for capacity.

If the project is ready for a scale-up, request a temporary quota and GPU priority window from the administrators. Include the project, GPU type/count, resource preset, reason the workload is ready, requested start date, requested number of weeks, expected utilization, and a checkpoint/recovery plan. A grant ends when the agreed window ends and the project returns to its normal over-quota state.

Escalate with the workload name, project, requested resource, state, and timestamp. Do not treat a priority request as a guarantee of immediate GPU capacity.

Container exits immediately, GPU is missing, or distributed startup fails

Read the first relevant application error in the workload logs. Verify the command, image tag, mounted data path, and selected resource. For distributed runs, confirm the launcher’s process count matches the visible GPU allocation.

SSH failure or missing files

Confirm the workload is still running and EduVPN is connected. Recreate the approved forwarding path. Check whether files were placed in ephemeral storage; ephemeral data does not survive workload deletion.

Escalate with useful information

Include the project, workload name, approximate time, current state, safe log excerpt, image tag, selected compute resource, and steps already tried. Omit all secrets and personal data.