Troubleshooting#

Answers to the most common problems on the myDelska platform. If your issue is not listed here, contact Support.

I can’t connect to my VM via SSH#

The fix depends on the exact error message. Run SSH in verbose mode to see what happens during the connection:

ssh -v username@<public_IP_address_of_VM>

Then find your error below.

“Connection refused”#

Your packets reach the VM, but nothing accepts them on port 22:

The VM is in Running status in the Dashboard.
You are connecting to the correct public IP address (Dashboard » Instances » Network).
The SSH service on the VM may be stopped. Log in through the VNC Console and check it:
```
systemctl status ssh    # Debian/Ubuntu
systemctl status sshd   # AlmaLinux/Rocky/CentOS
```
Start it with systemctl start ssh (or sshd) if it is inactive.
A firewall inside the OS (ufw, firewalld, iptables) may be rejecting port 22 — this is separate from the Dashboard firewall rules.

“Connection timed out”#

Your packets don’t reach the VM at all:

An inbound firewall rule must allow TCP port 22 from your IP address. If the rule is limited to a specific IP, check that your current public IP hasn’t changed.
The VM is in Running status.
Some office and public networks block outbound SSH — try another network (e.g. a mobile hotspot) to rule this out.

“Permission denied (publickey)”#

The network connection works, but authentication fails:

Use the correct username for your OS image (for example, root).
Point the client to the right private key: ssh -i ~/.ssh/id_rsa username@<IP> — it must match the public key selected during deployment.
On Linux/macOS, the private key file must not be world-readable: chmod 600 ~/.ssh/id_rsa.
If the wrong key was selected at deployment, log in through the VNC Console and add your public key to ~/.ssh/authorized_keys.

“Remote host identification has changed”#

This warning appears when the host key stored on your computer no longer matches the VM — typically after the VM was rebuilt or its IP address was reused. If you know why the key changed, remove the old entry and reconnect:

ssh-keygen -R <public_IP_address_of_VM>

I can’t connect to my Windows VM via RDP#

Most often the cause is one of these:

No inbound firewall rule allowing TCP port 3389 from your IP address.
Wrong credentials — reset the Administrator password in the VM Settings.
A CredSSP / “encryption oracle remediation” error — install Windows updates on your local computer and on the VM (via the VNC Console).

The full checklist for Windows, macOS, and Linux clients is in Connect to Windows VM via RDP.

My VM won’t start#

If your VM doesn’t start, or starts and immediately stops:

Check the credit balance of the Workspace — services are stopped when credit runs out, see Billing Methods.
Check the Activity report to see which action failed and whether another user stopped the instance.
Try a full Stop followed by Start instead of a restart.
Open the VNC Console and watch the boot process — OS-level problems (broken /etc/fstab entry, filesystem check, kernel error) are visible there. A typical example: a deleted extra disk still listed in /etc/fstab stops the boot.
If the OS is damaged, restore the VM from a backup. If nothing helps, contact Support with the instance name and the time the problem started.

My website on the VM is not reachable#

The VM works, but a site or application hosted on it doesn’t open from the Internet:

Check that the service is running and listening on the expected port — on the VM, run:
```
ss -tlnp | grep -E ':80|:443'
```
Add inbound firewall rules for TCP 80 and 443 (they are not open by default when other rules exist).
Test locally first: curl -I http://localhost on the VM. If this works but external access doesn’t, the problem is a firewall — either in the Dashboard or inside the OS (ufw, firewalld).
If you use a domain name, verify its DNS record points to the VM’s current public IP address.

I forgot my VM password#

Reset the password in the VM Settings section. The password is used for Console access; for SSH access, use your SSH key.

My VM is unreachable after I changed firewall rules#

Applying a firewall policy overwrites custom rules on the selected VMs, and assigning a port blocks all other traffic in that direction. Review the rules of the affected instance (Instance » Network) and make sure the ports you need (e.g. 22 for SSH, 3389 for RDP, 80/443 for web) are allowed. If you locked yourself out, use the VNC Console.

I can’t send email from my VM (port 25)#

Outbound traffic on TCP port 25 (SMTP) is blocked by default on new accounts to prevent spam. To unblock it, submit a request through the Support section in myDelska — see Registration restrictions.

I didn’t receive the verification email#

Check your spam folder and make sure the address was entered correctly. If the email still doesn’t arrive, contact Support.

My services stopped or disappeared#

This usually means the Workspace ran out of credit. Services are stopped 7 days after a missed payment, and deleted together with their data if payment is still not received — see Billing Methods. Check your balance in the Billing section and top up your credit.

Prevention: keep your balance topped up and create regular backups. Deleted services and data cannot be restored.

My extra disk doesn’t show up in the OS#

An added disk is not mounted automatically. Follow the Linux or Windows steps in Create extra disk. On Linux, also make sure the partition is listed in /etc/fstab, otherwise it disappears after a reboot.

I lost my 2FA device and can’t log in#

Use one of the backup codes you saved when enabling two-factor authentication. If you have no backup codes, contact Support to verify your identity and recover the account.

I can’t delete my Workspace#

A Workspace can only be deleted when all its instances are destroyed and the credit balance is zero — see Create Workspace.

The network feels slow from my location#

Check the real-time latency from your region to EU North on the Latency Overview page, and verify your VM’s bandwidth plan — the default is 100 Mbps and can be upgraded up to 1 Gbps.

My VM is slow or CPU is at 100%#

Check the graphs in Monitoring to see whether CPU, RAM, disk, or network is the bottleneck, and set alerts so you notice it next time.
On the VM, find the process consuming resources: top or htop on Linux, Task Manager on Windows.
If the load is legitimate and constant, upgrade the VM plan to get more CPU and RAM.
A full disk can also make a VM crawl — check with df -h and add an extra disk if needed.

Still stuck?#

Submit a request through myDelska Support. Include the affected instance name, timestamps, and what you have already tried — it speeds up the resolution. See Support & Help for response times.