Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt

Use this file to discover all available pages before exploring further.

Updated May 8, 2026 The most-seen failures with Raff VMs and the fix that works in each case. If your issue isn’t here, contact support@rafftechnologies.com.

​
Connection problems

What’s happening: ssh: connect to host x.x.x.x port 22: Connection refused.Likely causes & fixes:
  1. Security group blocks port 22 — open the VM’s Firewall and confirm an inbound TCP/22 rule exists for your IP.
  2. SSH daemon isn’t running — open the VNC console, log in, run systemctl status ssh (Ubuntu/Debian) or systemctl status sshd (RHEL family). Start it with systemctl start ssh and persist with systemctl enable ssh.
  3. sshd is listening on a different port — cat /etc/ssh/sshd_config | grep -i ^Port. Connect with ssh -p <port> root@… or change the rule.
What’s happening: ssh: connect to host x.x.x.x port 22: Operation timed out.Likely causes & fixes:
  1. VM not active — check the dashboard. If it’s passive, start it. If provisioning while a snapshot/backup runs, wait for it to finish (see Lifecycle states).
  2. Public IP changed — confirm the IP shown in the dashboard matches what you’re connecting to.
  3. Inside-the-VM firewall — ufw/iptables/firewalld may be blocking 22. Use the VNC console and disable or fix the rule (ufw allow 22, firewall-cmd --add-service=ssh --permanent).
  4. Network outage — check status.rafftechnologies.com.
What’s happening: SSH reaches the daemon but rejects the key.Fixes:
  1. Wrong key — ssh -i ~/.ssh/specific_key root@… to point at the right private key.
  2. Key permissions too open — chmod 600 ~/.ssh/<key> on macOS/Linux.
  3. Key not in authorized_keys on the VM — open the VNC console, log in, and append your public key to ~/.ssh/authorized_keys (chmod 600 and chown user:user).
  4. Password auth disabled, no key set — Reset password and connect over the VNC console once first to add a key.
What’s happening: RDP authenticates but the desktop never appears.Fix: Open the VNC console, send Ctrl+Alt+Del, choose Sign out, then reconnect over RDP.
What’s happening: Your client warns about a self-signed certificate.Fix: Expected. Accept and continue, or install a public CA cert inside the VM and restart the RDP service.

​
Disk and filesystem

What’s happening: SSH session ends immediately, or commands return No space left on device.Fix via VNC:
  1. Open the VNC console.
  2. Log in. Identify the largest paths: du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20.
  3. Common culprits: /var/log (rotate or truncate logs), /var/cache/apt (apt clean), /tmp (rm -rf /tmp/* if safe), Docker layers (docker system prune -a).
  4. If still tight, resize the disk (one-way grow), then expand the filesystem inside the VM.
What’s happening: Boot drops to emergency shell or hangs after Welcome to GRUB.Fix via VNC + single-user mode:
  1. Open the VNC console and reboot the VM (hard reboot if needed).
  2. At the GRUB menu, press e on the highlighted entry.
  3. Find the line beginning linux …. Append single (or init=/bin/bash) at the end.
  4. Press Ctrl-X to boot.
  5. Remount root read-write: mount -o remount,rw /.
  6. Edit /etc/fstab with vi and either fix or comment out the bad line.
  7. Reboot normally.
What’s happening: You attached a volume in the dashboard, but lsblk doesn’t show it.Fix:
  1. Re-scan SCSI — echo "- - -" > /sys/class/scsi_host/host0/scan (Linux).
  2. Check it’s the right VM — volumes attach to a single VM at a time; make sure the dashboard shows the attachment to this VM.
  3. Expected device — virtio devices appear as /dev/vdX on Linux. See Volumes → Attach to a VM for the full mount flow.

​
Lifecycle and state

What’s happening: Status hasn’t moved to active after several minutes.Fix:
  1. Wait 5-10 minutes — large templates and busy regions take longer.
  2. If stuck > 10 minutes, contact support with the VM ID.
  3. If status moves to failure, the VM is non-billable — delete and recreate. If it persists, support can investigate the underlying node.
What’s happening: A previously active VM shows provisioning but SSH/RDP still works.Cause: A snapshot or backup is running. The dashboard reuses the provisioning label while the hypervisor captures state. The VM continues serving traffic the whole time.Fix: Wait for the capture to finish — snapshots are typically 1–2 minutes, backups around 3 minutes on average; both scale with the size of the disk being captured. See Lifecycle states.
What’s happening: Compute resize rejects the request.Fix: Resize requires passive state. Stop the VM, wait for passive, resize, then start.
What’s happening: Dashboard shows the new plan; OS still reports the old.Fix: Reboot the VM. RAM/CPU changes need a fresh boot to be picked up.
What’s happening: The block device is bigger but the filesystem hasn’t been told.Fix: Inside the VM:
growpart /dev/vda 1     # if partitioned (replace with your disk)
resize2fs /dev/vda1     # ext4
# or
xfs_growfs /             # xfs
See Volumes → Resize a volume for the volume case.

​
Networking

What’s happening: curl https://example.com hangs or returns network unreachable.Fix:
  1. Confirm the VM has a public IPv4 in the dashboard.
  2. Check inside-the-VM routing: ip route should show a default route through the gateway.
  3. Restart networking: systemctl restart systemd-networkd (or NetworkManager).
  4. Check inside-the-VM firewall (ufw status, iptables -L).
What’s happening: Your VM’s public IPv4 differs from the one you remembered.Cause: Factory reset, reinstall (rarely), or the IP was a regular ephemeral one and the VM was deleted-and-recreated.Fix: For a stable address across rebuilds, reserve a Public IP and assign it.
What’s happening: Private-IP traffic between two of your VMs doesn’t work.Fix:
  1. Confirm both VMs share the same VPC (VM detail page → Network section).
  2. Check security groups on both VMs allow the protocol/port between private IPs.
  3. Check inside-the-VM firewalls.
  4. Use private IPs, not public, for VPC-internal traffic.

​
Backups and snapshots

What’s happening: Schedule exists but no new backups appear.Fix:
  1. Confirm the schedule is enabled on the VM detail page → Backups tab.
  2. Time window — note the platform’s timezone vs yours.
  3. The VM must be active for backups to run; a stopped VM is skipped.
What’s happening: Snapshot returns an error or stays in failed.Fix:
  1. VM must be active — snapshots of passive VMs are not supported.
  2. Delete the failed entry and retry.
  3. If it keeps failing on the same VM, contact support with the VM ID.

​
Authentication and access

What’s happening: Lost the password from the original create flow.Fix: Open the VM detail page → Credentials card → Send to Email (sends the existing password). If that still doesn’t work, Reset password — generates a new one and emails it.
What’s happening: SSH key lost, password unknown, can’t log in via VNC.Fix:
  1. Reset password — the new password lands by email; use the VNC console once it arrives.
  2. If reset doesn’t work, Factory reset the VM (preserves attached volumes, snapshots, backups; wipes the OS disk).
  3. If you need the OS disk’s contents preserved, contact support with the VM ID — recovery from a backup may be possible if you have one. This is why production VMs should always run a backup schedule.

​
Billing

Cause: Stopped VMs (passive) keep their CPU, RAM, disk, and IP reservations and continue to be billed under their subscription term. To stop charges, delete the VM — unused subscription days are credited back to your account balance.
Cause: Downsize resizes credit the prorated difference back to your account balance, not to the original card. Check Billing → Account Balance.

​
Still stuck?

Contact support@rafftechnologies.com with:
  • The VM ID (from the dashboard URL or Get VM response)
  • The exact error message and timestamp
  • Steps already tried
  • Relevant logs from inside the VM (journalctl -xe, /var/log/syslog)
Last modified on May 8, 2026