Essential Linux Commands for Server Administration

You don't need to memorise hundreds of commands to run a Linux server. About 25 of them let you move around the filesystem, read logs, check disk space, manage processes and services, troubleshoot the network and fix file permissions. This guide groups those commands by the job you're trying to do and gives a real-world example for each.

Every example works on Ubuntu 24.04, and almost all of them behave the same on other distributions (Debian, Rocky and so on). If you aren't connected to your server yet, start with connecting over SSH and creating a key. There's a cheat sheet at the end worth bookmarking.

Short answer: The Linux commands you'll use most on a server are ls, cd and less for files; tail -f and journalctl for logs; df -h and du for disk space; htop, ps and free -h for resources; systemctl for services; ss and curl for networking; and chmod and chown for permissions. Those 25 or so commands cover most day-to-day work on an Ubuntu server.

Navigating files and directories#

pwd                       # where am I?
ls -lah /var/www          # detailed listing, human-readable sizes, hidden files included
cd /etc/nginx             # change directory; cd - jumps back to the previous one
cat /etc/os-release       # print a short file in full
less /var/log/syslog      # page through a long file; / to search, q to quit

To create, copy, move and delete:

mkdir -p /srv/app/releases     # create a directory and any missing parents
cp -a config.php config.php.bak    # copy, preserving permissions and timestamps
mv old.log archive/            # move or rename
rm -r /tmp/build-cache         # delete a directory

rm has no recycle bin. Before any rm -rf, run ls on the same path first, especially when the path contains a variable.

Reading logs#

Most server troubleshooting comes down to reading logs. There are two main sources: the files under /var/log and the systemd journal.

tail -n 100 /var/log/nginx/error.log      # last 100 lines
tail -f storage/logs/laravel.log          # follow live; Ctrl+C to stop
journalctl -u nginx --since "1 hour ago"  # one service's logs from the last hour
journalctl -u php8.3-fpm -f               # follow one service's logs live
journalctl -p err -b                      # errors only, since the last boot

tail -f is probably the single most useful debugging command: leave it running in one terminal and reproduce the error in another.

Disk space#

A full disk is one of the most common reasons a server suddenly breaks: the database can't write, logging stops and sessions can't be created.

df -h                                  # free space on each partition
du -sh /var/log                        # total size of a directory
du -h --max-depth=1 /var | sort -h     # which subdirectory is the biggest?

The usual way to find the culprit: use df -h to see which partition is full, then drill down level by level with du and sort -h until you reach the large directory. If the systemd journal has grown too big, sudo journalctl --vacuum-size=200M shrinks it. For a full walkthrough, see what to do when a Linux server's disk is full.

Processes and resource usage#

top                         # live CPU and RAM view; q to quit
htop                        # a friendlier top (sudo apt install htop)
free -h                     # RAM and swap usage
ps aux | grep php           # find a program's processes
kill 12345                  # politely ask a process to stop, by PID
kill -9 12345               # force-kill, only when a plain kill didn't work

In free -h, look at the available column, not free. Linux uses spare RAM for disk cache, and that's normal.

A plain kill sends SIGTERM, which gives the program a chance to shut down cleanly. kill -9 (SIGKILL) doesn't, so it's a last resort. For services managed by systemd, don't use kill at all; use systemctl.

Managing services with systemctl#

The web server, PHP-FPM, the database and queue workers are all systemd services:

systemctl status nginx              # state, PID and the last few log lines
sudo systemctl restart nginx        # restart
sudo systemctl reload nginx         # re-read config without dropping connections
sudo systemctl enable --now redis-server   # start at boot and start right now
systemctl --failed                  # which services have failed?

Before you reload or restart a web server, test the configuration with sudo nginx -t. One typo in a config file plus a hasty restart can take every site on the server offline. If you run Laravel queue workers under systemd, the details are in offloading slow work to queues.

Networking#

ss -tulpn                              # which process is listening on which port?
curl -I https://example.com            # HTTP response headers only
curl -sS localhost:8000/health         # test a service from the server itself
ping -c 4 1.1.1.1                      # do we have internet access at all?
ip -br a                               # IP addresses of the network interfaces
dig +short example.com                 # which IP does the domain point to?

A typical troubleshooting order when a site won't load: check the service is running with systemctl status, check it's listening on the right port with ss -tulpn, test it from inside the server with curl, and if it works locally but not from outside, look at the firewall or DNS. For DNS, see DNS records explained. (dig ships in the bind9-dnsutils package.)

Permissions and ownership#

chown -R deploy:www-data /var/www/app           # change owner and group
chmod 640 .env                                   # owner reads and writes, group reads only
chmod -R 775 storage bootstrap/cache             # directories the web server must write to
sudo -u www-data php artisan cache:clear         # run a command as another user

A numeric chmod mode has three digits: owner, group, others. Each digit is the sum of 4 (read), 2 (write) and 1 (execute), so 7 means everything, 6 means read and write, and 4 means read-only. Whenever you're tempted to fix a permission error with chmod 777, stop: the problem is almost always the wrong owner or group, not missing permissions.

Archiving and compression with tar#

tar -czf app-2026-10-09.tar.gz /var/www/app      # create a compressed archive
tar -tzf app-2026-10-09.tar.gz | head            # list contents without extracting
tar -xzf app-2026-10-09.tar.gz -C /tmp/restore   # extract into a specific directory

Remember the letters as: c create, x extract, t list, z gzip and f file name. An archive isn't a backup until a copy also lives on another machine; see the 3-2-1 backup rule.

Finding files and text#

find /var/www -name "*.log" -size +100M          # log files larger than 100 MB
find /tmp -type f -mtime +7                      # files not modified in over 7 days
grep -rn "DB_HOST" /var/www/app/config           # search text in every file under a directory
grep -i "error" storage/logs/laravel.log | tail  # latest errors, case-insensitive

grep composes with pipes (|), which multiplies its usefulness. For example, this shows the ten most frequent IPs in the nginx access log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Habits that save you trouble#

• Make a .bak copy before editing any config file.
• Work as a non-root user and use sudo only where needed. The setup is covered in the first hour on a new Linux server.
• Don't forget man and --help: man tar or ss --help is faster than any web search.
• Turn repetitive commands into scripts or cron jobs.
• Use history | grep to find the command you ran yesterday, and Ctrl+R to search your history interactively.

Cheat sheet: 25 essential commands#

Frequently asked questions#

What is the difference between systemctl restart and reload?#

restart fully stops and starts the service again, dropping current connections. reload only re-reads the configuration and keeps connections open, so for nginx reload is usually the better choice after a config change, once sudo nginx -t has passed.

How do I find which process is using a port in Linux?#

sudo ss -tulpn lists every listening TCP and UDP port along with the process name and PID. To check one port, filter the output with grep, for example sudo ss -tulpn | grep :80.

Why is chmod 777 a bad idea?#

777 gives every user on the system read, write and execute access, so any other process or user can modify the file. Permission errors almost always come from the wrong owner or group, and the right fix is chown plus modes such as 640 or 775.

What is the difference between kill and kill -9?#

A plain kill sends SIGTERM, giving the program a chance to finish cleanly. kill -9 sends SIGKILL, which terminates the process immediately, so use it only when a normal kill hasn't worked.

How do I check free disk space on a Linux server?#

df -h shows total, used and available space for each partition in human-readable units. To find the large directories, use du -h --max-depth=1 piped into sort -h.

Wrap-up#

Running a Linux server is less about memorising commands and more about knowing which tool answers which question: read logs with tail and journalctl, check disk with df and du, processes with htop and ps, services with systemctl, and the network with ss and curl. These 25 commands cover a large share of daily work. Be careful with rm and chmod, test configuration before restarting, and open man whenever you're unsure.