The rm command deletes files immediately and permanently. There's no trash can, no undo, and no confirmation prompt by default. Before you run it, list the target with ls to confirm exactly what matches, and if you're at all unsure, add the -i flag so the shell asks you to confirm each file.
Get in the habit of running the command that shows you what will be deleted before the command that deletes it.
Basic usage
To delete a single file over SSH:
rm filename.txt
To delete multiple files at once:
rm file1.txt file2.txt file3.txt
To delete a directory and everything inside it, add -r (recursive):
rm -r old-folder/
Without -r, rm refuses to touch directories at all, which is a small built-in safety net worth keeping. Don't reach for -rf as a habit to skip that refusal. The -f (force) flag suppresses prompts and ignores missing-file errors, which is exactly what you don't want while you're still confirming a path.
Confirm before you delete
Two habits catch most mistakes:
- Run
lson the exact path first, so you see what actually matches beforermtouches it. This matters most with wildcards:rm *.logdeletes every file ending in.login the current directory, and a stray space or wrong working directory can turn a narrow cleanup into a wide one. - Add
-ito have the shell askrm: remove regular file 'x.txt'?for each match. It's slower, but for anything with a wildcard or a directory tree, it's worth it:rm -i *.tmp.
Also check your working directory with pwd before running anything with a wildcard. A command that's safe in ~/public_html/cache/ is not safe if you're accidentally sitting in ~/public_html/.
Where this applies on Flashcloud
On shared and WordPress hosting, you'll mostly use rm through SSH inside your account's home directory or web root, cleaning up old backups, stale cache files, or leftover install archives. File Manager in the portal offers the same file operations if you'd rather delete visually with a confirmation dialog instead of the command line. That's often the safer choice for a one-off cleanup, since it shows you the file list before anything is removed.
On a VPS, you have root access and full responsibility for the OS, which means rm has no guardrails at the account level the way shared hosting does. A misplaced rm -rf as root can remove system files, not only your application's data. Always double check the path with pwd and ls before running anything recursive and forced as root, and never run rm -rf against a path built from a variable you haven't printed and verified first.
If you're running low on disk space
Before deleting files to free up space, it's worth knowing what's actually taking up room. See checking your hosting resource usage for how to check disk usage in the portal and in cPanel's Resource Usage tool, so you're removing the right things instead of guessing.
What to do if you deleted the wrong thing
Once rm runs, the file is gone from the filesystem. There's no recycle bin to check. Your options at that point are a backup or a restore, not recovery from the command line.
- If you have a recent backup, restoring from it is the fastest path back. Check Backups on your service page, or open a ticket to see what restore points are available on shared and WordPress hosting.
- If the deleted files were part of a WordPress site, ask support which restore points are available before assuming nothing can be recovered.
- On a VPS, restoring means using your own snapshot or backup strategy, since there's no automatic account-level backup layer standing between you and the OS.
When to contact support
If you've deleted something important and don't have a way to restore it yourself, open a ticket from Support in the portal. A real person can check what backup points are available and walk you through restoring one, and the sooner you reach out after the deletion, the more restore options support can check for you.