The essential Linux command line guide for server owners

If you rent a server, sooner or later you'll end up staring at a black terminal window with a blinking cursor. This guide walks you through the Linux commands that actually matter when you run a server, with real examples you can copy and try. By the end you'll be able to move around the filesystem, edit files, fix permissions, check what's eating your memory, and restart a service without panicking.

It's written for someone who manages a box (a game server, a VPS, a web host) but doesn't think of themselves as a Linux person. You don't need to memorize everything. Keep the cheat sheet at the bottom open in a second tab and you'll be fine.

Getting around the filesystem

Everything in Linux lives in one big tree that starts at /, the root. When you log in you usually land in your home folder, something like /home/dominic. Three commands let you walk that tree.

pwd tells you where you are right now. It stands for print working directory.

$ pwd
/home/dominic

ls lists what's in the current folder. On its own it's plain. Add -l for a detailed list and -a to show hidden files (the ones that start with a dot). I use ls -la almost every time.

$ ls -la
total 28
drwxr-xr-x 4 dominic dominic 4096 Jun 27 10:14.
drwxr-xr-x 3 root    root    4096 Jun 01 09:02..
-rw-r--r-- 1 dominic dominic  220 Jun 01 09:02.bashrc
drwxr-xr-x 2 dominic dominic 4096 Jun 27 10:14 server
-rw-r--r-- 1 dominic dominic  512 Jun 27 10:10 notes.txt

cd changes directory. Give it a path to move there. A few shortcuts save a lot of typing:

$ cd server          # go into the server folder
$ cd..              # go up one level
$ cd ~               # jump back to your home folder
$ cd /var/log        # go straight to an absolute path
$ cd -               # go back to the folder you were just in

One thing that trips people up early: a path that starts with / is absolute (measured from root), and a path that doesn't is relative (measured from where you are). So cd logs looks for a logs folder inside the current one, while cd /logs looks at the very top of the tree.

Working with files and folders

Now the bread and butter. These are the commands you'll reach for when you're copying a config, deleting an old world backup, or peeking at a log.

• mkdir makes a new folder. Add -p to create parent folders in one go.
• cp copies a file. Add -r to copy a whole folder.
• mv moves a file, and it also renames files (moving a file to a new name is the same thing).
• rm deletes. Add -r for folders. There is no recycle bin, so be careful.

$ mkdir -p backups/2026-06
$ cp server.properties server.properties.bak
$ cp -r world backups/2026-06/
$ mv old-config.yml config.yml      # rename
$ mv config.yml /etc/myapp/         # move
$ rm server.properties.bak
$ rm -r backups/2026-05             # delete a whole folder

A word about rm -rf. The -f means force, no questions asked. It's handy and dangerous. Never run rm -rf while you're unsure which folder you're in, and never type it near /. If you want a safety net, add -i and Linux will ask before each delete.

To read files without opening an editor, you've got three good options. cat dumps the whole file to the screen, which is fine for short files. less opens a scrollable view (press q to quit, / to search). And tail shows the end of a file, which is perfect for logs.

$ cat config.yml
$ less /var/log/syslog
$ tail -n 50 /var/log/nginx/error.log     # last 50 lines
$ tail -f latest.log                       # follow new lines live

That tail -f is one you'll use a lot. It keeps printing new lines as they arrive, so you can watch a server log in real time while something is happening. Press Ctrl+C to stop following.

When you need to actually change a file, nano is the friendliest editor. It shows the key commands along the bottom. The two you need are Ctrl+O to save (it calls this write out) and Ctrl+X to exit.

$ nano server.properties

People will tell you to learn vim instead. You can, later. For editing a config quickly, nano gets the job done and never traps you in a mode you can't escape.

Permissions without the headache

Every file in Linux has an owner, a group, and a set of permissions that decide who can read, write, or run it. This is the part that confuses newcomers, so let's make it simple.

Look again at a line from ls -l:

-rw-r--r-- 1 dominic dominic 512 Jun 27 10:10 notes.txt

That first block, -rw-r--r--, is the permission string. Ignore the first character (it just says file or folder). The remaining nine characters come in three groups of three:

• The first three are for the owner (here dominic).
• The middle three are for the group.
• The last three are for everyone else.

Inside each group, r is read, w is write, and x is execute (run). A dash means that permission is off.

You'll often see permissions written as numbers like 755 or 644. Each digit is just read+write+execute added up, where read is 4, write is 2, and execute is 1. So 7 is all three (4+2+1), 6 is read and write (4+2), 5 is read and execute (4+1), and 4 is read only. The three digits map to owner, group, everyone, in that order.

So 755 means the owner can do everything, and everyone else can read and run but not change. That's normal for a folder or a script. 644 means the owner can read and write, everyone else can only read. That's normal for a config or text file.

chmod changes the permissions. You can use the numbers, which is the quickest way once it clicks.

$ chmod 644 server.properties     # owner read/write, others read
$ chmod 755 start.sh              # make a script runnable
$ chmod +x start.sh              # shortcut: just add execute

chown changes who owns the file. The format is owner:group. This matters a lot on web servers, where files often need to belong to a user like www-data so the web server can read them.

$ sudo chown dominic:dominic notes.txt
$ sudo chown -R www-data:www-data /var/www/mysite    # whole folder

That -R applies the change to everything inside the folder too. A huge share of real world permission problems come down to a file being owned by the wrong user, so chown -R is often the fix.

Seeing and stopping processes

A process is just a running program. When your server feels stuck or something won't restart, you need to find the process and sometimes stop it.

ps aux lists every running process. It's a lot of output, so pipe it into grep to filter for what you want.

$ ps aux | grep java
dominic  4821  3.4 18.2 5123400 745200?  Sl  10:02  2:13 java -Xmx4G -jar paper.jar

The second number on that line, 4821, is the process ID (the PID). You use the PID to stop a process with kill.

$ kill 4821          # ask it politely to stop
$ kill -9 4821       # force it to stop if it ignores you

Start with a plain kill. It sends a signal that lets the program shut down cleanly, which matters for a game server that needs to save the world. Only reach for kill -9 when a process is truly frozen, because it pulls the plug with no chance to save.

For a live view, htop is far nicer than the older top. It shows CPU and memory bars, sorts by usage, and lets you kill a process by pressing F9. It isn't always installed, so you may need to add it first.

$ sudo apt install htop     # Debian or Ubuntu
$ htop

Inside htop, press q to quit. It's the first thing I open when a server feels slow, because it shows at a glance whether you're out of CPU, out of memory, or fine.

Checking disk and memory

Running out of disk space is one of the most common reasons a server suddenly stops working. Logs grow, backups pile up, and one day there's no room left. Three commands keep you ahead of it.

df -h shows how full each disk is. The -h means human readable, so you get GB instead of raw blocks.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   54G   23G  71% /
tmpfs           2.0G     0  2.0G   0% /dev/shm

Look at the Use% column. If your main mount (usually /) is near 100%, that's your problem. To find what's hogging the space, du -sh measures the size of a folder.

$ du -sh /var/log
1.8G    /var/log
$ du -sh *           # size of each item in the current folder
512M    world
2.1G    backups
44M     plugins

So here the backups folder is the big one. free -h does the same human readable trick for memory.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       4.2Gi       1.1Gi        96Mi       2.5Gi       3.3Gi

The column to trust is available, not free. Linux deliberately uses spare memory for caching, so a low free number is normal and healthy. If available gets very small, that's when you should worry.

Finding things

Two commands handle almost all searching. find looks for files by name, and grep looks for text inside files.

find takes a starting folder and what to look for. To find a file by name:

$ find /home/dominic -name "server.properties"
/home/dominic/server/server.properties

$ find. -name "*.log"          # all.log files under the current folder
$ find /var/www -type d -name "uploads"    # find a folder named uploads

grep searches inside files for a word or pattern. Add -r to search through a whole folder, and -i to ignore case.

$ grep "ERROR" latest.log
$ grep -ri "database" /etc/myapp/      # find which config mentions database
$ grep -n "port" server.properties     # -n shows line numbers

You'll also use grep to filter the output of other commands by piping with the | symbol, like the ps aux | grep java trick from earlier. The pipe sends the output of the left command into the right one. It's one of the most useful ideas in the shell.

Downloading files

When you need to pull a server jar, an installer, or a config from the internet, you've got two tools. wget is the simple one for downloading a file to disk.

$ wget https://example.com/paper-1.21.jar
$ wget -O server.jar https://example.com/paper-1.21.jar   # save under a chosen name

curl is more flexible and is great for talking to APIs, but for a plain download you'll want the -O flag (capital O) so it saves the file with its original name, or -L to follow redirects.

$ curl -L -O https://example.com/installer.sh

A quick safety note. People will tell you to run scripts straight from the internet with something like curl... | bash. Download the script first, open it with less, read what it does, then run it. Two extra minutes can save you from a very bad day.

Managing services with systemctl

Most things that run in the background on a modern Linux server (your web server, your database, a bot you set up as a service) are managed by systemd. The command to control them is systemctl, and you'll almost always run it with sudo.

The four actions you need most:

$ sudo systemctl status nginx     # is it running? show recent logs
$ sudo systemctl restart nginx    # stop then start it
$ sudo systemctl stop nginx       # stop it
$ sudo systemctl start nginx      # start it

The status output is your friend when something is broken. It shows whether the service is active, when it last started, and the last few log lines, which usually point straight at the problem.

$ sudo systemctl status nginx
   nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Fri 2026-06-27 09:14:02 UTC; 1h 3min ago

That word enabled means the service starts automatically on boot. If you set up a new service and it doesn't come back after a reboot, you probably forgot to enable it:

$ sudo systemctl enable myapp     # start automatically on boot
$ sudo systemctl disable myapp    # do not start on boot

For the full logs of a service, journalctl goes with systemd. The -u flag picks a unit and -f follows live, just like tail -f.

$ journalctl -u nginx -n 100      # last 100 log lines for nginx
$ journalctl -u nginx -f          # follow live

Working safely with sudo

sudo runs a single command as the administrator (root). You'll need it for anything that touches system files, installs software, or controls services. The habit to build is simple: use sudo only for the command that needs it, and read the command twice before you hit enter.

$ sudo apt update              # refresh the package list
$ sudo apt upgrade             # install available updates
$ sudo nano /etc/nginx/nginx.conf

Avoid logging in as root and staying there, and avoid running everything with sudo out of laziness. The whole point is that the extra word makes you pause before doing something with the power to break the machine. If a command fails with Permission denied and it's a legitimate system task, missing sudo is the usual reason.

Troubleshooting common errors

Here are the errors you'll bump into in your first week, and what they actually mean.

Permission denied. Either you need sudo for a system task, or the file is owned by another user. Check ownership with ls -l, and fix it with chown or by adding sudo. For a script that won't run, you may just need chmod +x on it first.

No such file or directory. Almost always a typo in the path, or you're not where you think you are. Run pwd to confirm where you are, and ls to see what's actually there. Remember that Linux is case sensitive, so Config.yml and config.yml are different files.

command not found. The program isn't installed, or it's not in your PATH. Install it with your package manager, for example sudo apt install htop. Tools like htop, curl, and even nano sometimes aren't there by default on a fresh server.

The disk is full and nothing works. Run df -h to confirm, then du -sh * from likely culprits like /var/log or your backups folder to find the bloat. Old logs and forgotten backups are the usual cause. Delete with care and double check the path first.

A service won't start. Run sudo systemctl status servicename and read the last few lines, then journalctl -u servicename -n 50 for more detail. The error is nearly always sitting right there in the log, often a typo in a config file or a port already in use.

Wrapping up

You now have enough of the Linux command line to run a server day to day. Move around with cd and ls, edit configs with nano, fix ownership with chown, watch a slow box with htop, free up space by hunting with du -sh, and restart anything with systemctl. The rest you'll pick up as you go, one command at a time.

The best way to get comfortable is to actually use it. If you run a server with us at Bytte.cloud you can open the console straight from the panel and try these out on a real box. Bookmark the cheat sheet below, and don't be afraid to read the manual for any command by typing man followed by its name, like man chmod.

Command cheat sheet