Linux commands explained from the ground up

Linux commands remain the most direct way to understand, operate and troubleshoot Linux systems. They are best learned as practical task families rather than as isolated syntax to memorize.

Introduction: Why Linux commands still matter

Linux commands are not just shortcuts for people who do not want to use a graphical interface. They are the natural language of the Linux operating system. When you open a terminal, you are not opening an old or limited tool. You are opening the most direct control layer of the system.

A graphical desktop shows icons, windows and menus. The command line shows the real structure underneath those visual elements. Files become paths. Programs become processes. Background applications become services. Storage becomes mounted filesystems. Internet connections become interfaces, routes, ports and packets. Permissions become visible rules that decide who can read, write or execute something.

This is why the Linux command line still matters everywhere: on personal computers, servers, Raspberry Pi devices, cloud infrastructure, containers, cybersecurity labs, development machines, hosting environments, routers, embedded devices, automation platforms and production systems. A person who understands Linux commands does not only know how to type instructions. They understand how the operating system thinks.

The goal of this guide is to explain Linux commands deeply, practically and clearly. It is not a dry list of commands. A list can help you remember syntax, but it does not teach real competence. Real competence comes from understanding what each command does, what problem it solves, what can go wrong, how it combines with other commands and how it fits into the larger structure of Linux administration.

A beginner often tries to memorize commands one by one. That is understandable, but it is not the best approach. Linux becomes much easier when you understand that commands belong to families of tasks.

The command line becomes powerful because Linux commands are designed to be combined. One command produces output. Another command filters it. A third command sorts it. A fourth command saves it. A fifth command can run the whole workflow every night.

This is one of the deepest ideas in Linux: a command is useful by itself, but a command pipeline can become a custom tool.

Why Linux commands are still essential

Linux commands remain essential because many important systems do not have a graphical desktop at all. Most production servers are managed through SSH. Cloud instances often start as minimal systems. Containers usually run without a graphical interface. Network devices, Raspberry Pi projects and embedded systems may expose only a shell. Even when dashboards exist, they often show only part of the truth.

The command line is also important because it is precise. When you click a button in a graphical interface, you may not know exactly what happened. When you run a command, the instruction is explicit. You can copy it, document it, repeat it, automate it and audit it.

This makes Linux commands especially valuable in professional environments.

A graphical interface is comfortable when everything works. The terminal is essential when something does not.

For example, a web application may show a generic error page. The real reason may be inside a log file. You might need to inspect the last lines of a log, search for a specific error, check whether the web server is running, verify disk space, restart a service and confirm that the port is listening.

That is not one command. It is a workflow.

tail -n 50 /var/log/syslog
grep -i "error" /var/log/syslog
df -h
systemctl status apache2
sudo systemctl restart apache2
sudo ss -tulpn

A person who only knows individual commands may see this as a collection of strange lines. A person who understands Linux sees a logical diagnostic sequence: read recent logs, search errors, check disk space, inspect service state, restart service, confirm network listening ports.

Why command combinations matter more than memorization

A single command answers a simple question. A combination answers a real operational question.

Simple question:

ls

What files are here?

Better question:

ls -lah

What files are here, including hidden files, with permissions and readable sizes?

Operational question:

find . -type f -name "*.log" -exec ls -lh {} \;

Which log files exist under this directory, and how large are they?

More operational:

find . -type f -name "*.log" -size +10M -exec ls -lh {} \;

Which log files are larger than 10 MB?

Even more useful:

find . -type f -name "*.log" -size +10M -exec gzip {} \;

Compress log files larger than 10 MB.

This progression shows how Linux thinking works. You begin by inspecting. Then you filter. Then you act.

Never skip directly to the action stage when using find, rm, chmod, chown or administrative commands.

Key takeaways

At this point, the foundation is clear. Linux commands operate inside a structured filesystem. Paths can be absolute or relative. Commands have options and arguments. Output can be displayed, filtered, redirected and combined. The safest workflow is to inspect before changing anything.

The core beginner commands are already enough to perform real work:

These commands are not “basic” in the sense of being unimportant. They are basic in the sense that everything else depends on them.

If you understand these commands deeply, then package management, permissions, services, networking, logs, processes, automation and scripting become much easier. Linux is not a collection of disconnected tools. It is a coherent environment built around files, processes, users, permissions and text streams.

How to think at the Linux command line

The command line becomes safer and more useful when it is approached with the right mental model: inspect first, understand the context, make controlled changes and verify the result.

The Linux command line mindset

Before learning syntax, it is important to understand the mindset. Linux does exactly what you tell it to do. It does not always ask whether you are sure. It does not always protect you from your own mistakes. It assumes that the user knows what they are doing, especially when administrative privileges are used.

This is both powerful and dangerous.

A careful Linux user follows a basic principle: inspect first, understand second, change third, delete last.

A beginner often wants to jump directly to action. An expert first gathers context.

For example, before deleting a directory, do not immediately run this:

rm -rf old-project

A safer workflow is:

pwd
ls -lah
du -sh old-project
tree -L 2 old-project
rm -ri old-project

This workflow confirms your location, lists the current directory, checks the size of the target, previews its structure and then removes it interactively.

Linux rewards this kind of discipline.

A professional mental model for Linux commands

Linux command-line work is not about typing fast. It is about thinking accurately.

A professional mental model follows these questions:

A beginner memorizes commands. An expert asks better questions.

Practical workflow: build a command-line investigation habit

When something is wrong, do not jump to solutions. Collect facts.

For a service problem:

hostname
uptime
df -h
systemctl status service-name
journalctl -u service-name -n 100
sudo ss -tulpn

For a disk problem:

df -h
sudo du -h --max-depth=1 / | sort -h
sudo find /var/log -type f -size +100M -exec ls -lh {} \;
sudo lsof | grep deleted

For a network problem:

ip a
ip route
ping -c 4 8.8.8.8
getent hosts example.com
sudo ss -tulpn

For a permission problem:

whoami
pwd
ls -ld .
ls -l target
namei -l /full/path/to/target

The command namei -l shows permissions along each component of a path. It is very useful for permission troubleshooting.

Example:

namei -l /var/www/site/uploads/image.jpg

This can reveal that the file itself is readable, but one parent directory blocks access.

Practical workflow: write commands as documentation

A good Linux command is also documentation. It shows what was done.

Compare this vague note:

I cleaned the logs.

with this clear command record:

sudo find /var/log/myapp -type f -name "*.gz" -mtime +30 -delete

The command tells you:

This is why command-line work is reproducible. The exact action can be reviewed and repeated.

For important operations, save the command and output.

sudo find /var/log/myapp -type f -name "*.gz" -mtime +30 -exec ls -lh {} \; | tee cleanup-preview.txt

Then after deletion:

sudo find /var/log/myapp -type f -name "*.gz" -mtime +30 -delete

Save a maintenance log:

{
    date
    hostname
    uptime
    df -h
    systemctl --failed
} | tee maintenance-check.txt

This creates a simple record of system state.

How to think about advanced shell work

Advanced shell usage is not about writing unreadable one-liners. It is about building reliable, inspectable workflows.

A good shell workflow has these qualities:

A bad shell workflow is clever but fragile. A good shell workflow is boring, explicit and safe.

For example, this is risky:

rm -rf $(find . -name "*.tmp")

This is better:

find . -type f -name "*.tmp" -print

Then:

find . -type f -name "*.tmp" -delete

Better still when learning:

find . -type f -name "*.tmp" -exec rm -i {} \;

The safest Linux users are not the slowest. They are the ones who build verification into their workflow.

Terminal, shell, commands and built-in help

Before individual commands make sense, the relationship between the terminal, the shell, command syntax and built-in documentation must be clear.

Understanding the terminal, shell and command

Many people use the words terminal, shell and command as if they were the same thing. They are related, but not identical.

When you type this:

ls -lah /home/pat

you are typing into a terminal. The shell interprets the line. The command is ls. The options are -lah. The argument is /home/pat.

The shell then runs the ls program and displays the result in the terminal.

A typical shell prompt may look like this:

pat@server:~/projects$

This can be understood as:

If the prompt ends with #, it often means you are acting as the root user.

root@server:/etc#

This deserves attention. A root shell can change or damage the entire system.

The basic structure of a Linux command

Most Linux commands follow a predictable structure.

command options arguments

A simple example:

ls

This runs the command ls without extra options or arguments.

A more specific example:

ls -lah /var/log

This command has three parts.

Options change how a command behaves. Arguments tell the command what to work on.

Short options usually begin with one dash.

ls -l

Long options usually begin with two dashes.

ls --all

Several short options can often be combined.

ls -l -a -h

can usually be written as:

ls -lah

This is why Linux commands may look cryptic at first. They are compact, but the logic is consistent.

Not every command supports the same options. You should not assume that -h, -r or -f always means the same thing in every command. Many common patterns exist, but the manual is the final authority.

Getting help from Linux itself

One of the most important commands is man, which opens the manual page for another command.

man ls

Inside a manual page, you can usually use these keys:

The manual page may seem dense, but it teaches you how Linux documents itself.

Most commands also support quick help.

ls --help

Another useful tool is type, which tells you what kind of command you are running.

type cd
type ls
type grep

Example output may show that cd is a shell built-in while ls is an external program.

cd is a shell builtin
ls is /usr/bin/ls
grep is /usr/bin/grep

This matters because some commands are built directly into the shell, while others are separate executable files.

You can also locate commands with:

command -v ls
which ls

A good learning habit is this:

command --help
man command
type command
command -v command

Replace command with the command you are learning.

type, command, which and whereis

Linux offers several ways to identify commands.

type ls

This tells whether ls is a shell built-in, alias, function or external command.

command -v ls

This prints the path or command resolution.

which ls

This often prints the path of the executable.

whereis ls

This can show binary, source and manual locations.

Comparison:

Examples:

type cd
type ls
type grep
command -v bash
whereis bash

You may see that cd is a shell built-in, while grep is an external program.

This distinction matters because built-ins affect the current shell. For example, cd must be a shell built-in because it changes the current directory of the shell itself.

man pages are the built-in university of Linux

The command man opens the manual page for a command.

man find

Manual pages are not always beginner-friendly, but they are precise and complete. A serious Linux user should learn how to read them.

A typical manual page has sections such as:

Inside man, use:

Example workflow:

man chmod

Search inside manual:

/recursive

Press n to move to the next occurrence.

Read the synopsis carefully. For example, syntax like this:

chmod [OPTION]... MODE[,MODE]... FILE...

has meaning.

Manual pages become easier once you understand their notation.

apropos searches manual descriptions

If you do not know the command name, use apropos.

apropos password

This searches manual page descriptions for the word password.

Another example:

apropos network

If apropos gives poor results, the manual database may need updating:

sudo mandb

The command apropos is useful when you know what you want to do but not which command does it.

Example:

apropos "disk usage"

You may discover commands such as du or related tools.

help for shell built-ins

Some commands are shell built-ins, not external programs. For Bash built-ins, use help.

help cd

help export

help history

You can also use:

type cd

If it says:

cd is a shell builtin

then help cd is often more relevant than searching for an external executable.

This matters for commands such as:

The shell itself is a tool, and built-ins are part of that tool.

The Linux filesystem, paths and essential directories

Linux commands operate inside a structured filesystem. Paths, core directories and file-like system interfaces explain where data lives and how Linux exposes system state.

The Linux filesystem as a tree

The most important structural idea in Linux is that the filesystem is a tree. Everything starts at /, called the root directory. Every file, folder, device and mounted disk appears somewhere under this root.

This is different from Windows, where drives are commonly shown as C:, D: and so on. Linux does not organize the system around drive letters. It organizes everything under one unified tree.

The root directory is written as:

/

A full path may look like this:

/home/pat/Documents/report.txt

This path can be read from left to right.

Linux paths are case-sensitive. This means:

Documents
documents
DOCUMENTS

are three different names.

This is a common source of beginner errors. If a folder is named Downloads, this command will fail:

cd downloads

The correct command is:

cd Downloads

Absolute paths and relative paths

A path tells Linux where something is. There are two main types: absolute paths and relative paths.

An absolute path always begins with /.

cd /home/pat/Documents

This command works no matter where you currently are, because it gives the full address.

A relative path does not begin with /.

cd Documents

This command depends on your current directory. If you are in /home/pat, it means /home/pat/Documents. If you are in /var/log, it means /var/log/Documents.

This is why pwd is so important. Before running commands that change files, always know your current location.

pwd

Example output:

/home/pat

A few special path symbols are used constantly.

Examples:

cd .

This technically means stay in the current directory.

cd ..

This moves one level up.

cd ~

This moves to your home directory.

cd /

This moves to the root directory.

cd -

This returns to the previous directory.

Essential Linux directories

Linux directories are not random. They follow a long-established structure. You do not need to memorize every directory immediately, but you should understand the major ones because they appear constantly in commands, logs, configuration and administration.

The most important practical distinction is between user space and system space.

Your home directory is usually safe for personal work.

/home/pat

System directories require caution.

/etc
/usr
/var
/boot
/dev

A useful rule is: inside your home directory you are usually managing your own data; outside your home directory you may be changing the operating system.

The root directory and the root user are not the same thing

Beginners often confuse / with the root user.

The root directory is the top of the filesystem.

/

The root user is the administrative superuser.

root

The root user’s home directory is:

/root

These are three related but different concepts.

This distinction matters. When someone says “go to root,” they may mean the root directory /. When someone says “run as root,” they mean run with administrative privileges. When someone says “root’s home,” they mean /root.

The deeper structure behind Linux commands

At this point, the command line is no longer just a set of tools. It is a coherent model of the operating system.

Linux exposes system reality through:

The same command patterns repeat everywhere.

To inspect:

ls
cat
less
systemctl status
journalctl

To search:

grep
find
awk

To count:

wc
uniq -c

To transform:

sed
awk
cut
sort

To act:

cp
mv
rm
chmod
chown
systemctl restart
apt install

To automate:

bash scripts
crontab
systemd timers

A beginner learns commands. An expert sees patterns.

Linux becomes powerful when you understand what is a file and what only looks like a file

One of the most important ideas in Linux is that many things are represented as files or file-like objects. This does not mean everything is a normal document stored on disk. It means the operating system exposes devices, processes, kernel information, terminals, sockets and system state through file paths.

This design gives the command line extraordinary power. You can inspect a process through /proc. You can inspect hardware through /sys. You can see devices in /dev. You can read logs in /var/log. You can configure services through text files under /etc. You can redirect output into files, read from files and connect commands through streams.

A beginner sees files as documents. A Linux administrator sees files as the interface of the operating system.

The directories /proc and /sys are especially important because they are virtual filesystems. Their contents are not ordinary files stored on disk. They are generated by the kernel to expose live information.

For example:

cat /proc/cpuinfo

shows CPU information.

cat /proc/meminfo

shows memory information.

ls /proc

shows many numbered directories. Those numbers are process IDs.

If a process has PID 1234, then this directory may exist:

/proc/1234

Inside it, Linux exposes information about that running process.

ls -lah /proc/1234

This can show process command line, environment, file descriptors, current working directory and executable path.

This is why Linux troubleshooting often feels transparent. The system exposes itself through inspectable paths.

Understanding /proc through real examples

The /proc filesystem is one of the most useful places for understanding a running Linux system. It contains live information about processes and kernel state.

Show CPU information:

cat /proc/cpuinfo

Show memory information:

cat /proc/meminfo

Show kernel command line used at boot:

cat /proc/cmdline

Show mounted filesystems:

cat /proc/mounts

Show uptime directly from proc:

cat /proc/uptime

Show load average:

cat /proc/loadavg

Many normal commands read from /proc internally or present the same kind of information in a more readable way.

This means Linux tools often transform raw system information into readable output.

For example, compare:

cat /proc/meminfo

with:

free -h

The first shows detailed raw memory fields. The second summarizes memory in a more human-friendly way.

Both are useful. The command is easier for daily work. The proc file is useful for deeper understanding and scripts.

Inspecting a running process through /proc

Suppose a process has PID 1234.

Show the command line that started it:

tr '\0' ' ' < /proc/1234/cmdline

Show the executable path:

readlink -f /proc/1234/exe

Show the process working directory:

readlink -f /proc/1234/cwd

Show open file descriptors:

ls -lah /proc/1234/fd

Show environment variables:

sudo tr '\0' '\n' < /proc/1234/environ

The null character \0 is used internally as a separator in some proc files, so tr converts it into spaces or new lines for readability.

This process inspection is extremely useful when you need to answer questions such as:

This is especially helpful when ps aux shows a process but not enough detail.

Example workflow:

ps aux | grep myapp

Find the PID, then:

readlink -f /proc/PID/exe
readlink -f /proc/PID/cwd
tr '\0' ' ' < /proc/PID/cmdline

Replace PID with the real process ID.

File descriptors explain open files and sockets

Every running process can have open file descriptors. A file descriptor is a numeric handle used by a process to read from or write to something.

Common file descriptors are:

But processes can have many more. They may point to files, pipes, sockets, devices or deleted files.

Inspect file descriptors for a process:

ls -lah /proc/PID/fd

You may see output like:

0 -> /dev/null
1 -> /var/log/myapp/output.log
2 -> /var/log/myapp/error.log
3 -> socket:[123456]
4 -> /var/lib/myapp/data.db

This tells you what the process is connected to.

A process writing to a deleted file may show something like:

1 -> /var/log/myapp/old.log (deleted)

This explains why disk space may remain used even after deleting a large file.

Use lsof for a more readable view:

sudo lsof -p PID

Find deleted open files:

sudo lsof | grep deleted

This is one of the most important advanced disk troubleshooting commands.

Understanding /dev and device files

The /dev directory contains device files. These are special files that represent devices or kernel interfaces.

List some devices:

ls -lah /dev | head

Common examples:

The special file /dev/null is used constantly in shell work.

Discard normal output:

command > /dev/null

Discard error output:

command 2> /dev/null

Discard everything:

command > /dev/null 2>&1

This is useful in scripts when you intentionally do not need output. But it can also hide errors, so use it carefully.

Example:

tar -tzf backup.tar.gz > /dev/null 2>&1

This tests whether the archive can be read without printing the file list. The exit status tells whether it succeeded.

echo $?

Understanding /run and runtime state

The /run directory stores runtime data. This data is created after boot and usually does not persist across reboots.

Examples include:

List /run:

ls -lah /run

Look for service-related runtime files:

ls -lah /run | head

Some services create sockets under /run.

Example:

find /run -type s 2> /dev/null | head

The -type s option in find searches for sockets.

Runtime files can explain how services communicate locally. For example, databases, PHP-FPM, system services and desktop sessions may use Unix sockets stored under /run.

A socket is not a normal text file. It is a communication endpoint.

Check file type:

ls -l /run/some-socket

You may see the first character s, meaning socket.

Understanding /etc as the configuration center

The /etc directory is where most system-wide configuration lives. It is one of the most important directories on a Linux system.

Examples:

Because /etc controls system behavior, editing it requires discipline.

A safe configuration editing workflow is:

sudo cp /etc/service/config.conf /etc/service/config.conf.$(date +%Y-%m-%d-%H-%M).backup
sudo nano /etc/service/config.conf

Then test if possible:

sudo service-name --test-config

Then reload or restart:

sudo systemctl reload service-name

Then verify:

systemctl status service-name
journalctl -u service-name -n 50

Never treat /etc as an ordinary personal notes folder. It is the control panel of the operating system.

The difference between configuration, state and data

Linux systems contain different kinds of information. Mixing them up causes bad backups, bad migrations and bad repairs.

This matters for backups.

A website may require:

A backup of /var/www/site alone may not be enough.

A migration plan should identify all required components.

Understanding /var/lib as application state

The directory /var/lib often stores application state and persistent data managed by services.

Examples may include:

Do not casually delete content from /var/lib. It may contain databases, package metadata or service state.

Check size:

sudo du -h --max-depth=1 /var/lib | sort -h

If /var/lib/docker is huge, the answer is not simply:

sudo rm -rf /var/lib/docker

That can destroy containers, images and volumes.

Instead, use the appropriate application tools.

The same logic applies to databases. Do not delete database files manually unless you understand the database engine and recovery plan.

Understanding /var/cache

The directory /var/cache stores cache data. Cache is usually rebuildable, but it can still matter.

Check size:

sudo du -h --max-depth=1 /var/cache | sort -h

APT package cache:

sudo du -sh /var/cache/apt

Clean APT cache:

sudo apt clean

Application caches may live under /var/cache, but do not delete them blindly. Some services expect cache directories to exist with correct ownership.

A safe cache cleanup process is:

sudo du -h --max-depth=1 /var/cache | sort -h

Then identify the application. Read documentation or service status. Stop the service if needed. Clean only the correct cache. Restart or reload. Verify logs.

Cache is generally less critical than data, but uncontrolled deletion can still cause service disruption.

Understanding /var/log as evidence

The directory /var/log is not just storage. It is evidence.

Before deleting logs, consider whether you need them for troubleshooting, security analysis or compliance.

Check log size:

sudo du -h --max-depth=1 /var/log | sort -h

Find large logs:

sudo find /var/log -type f -size +100M -exec ls -lh {} \;

Search errors:

sudo grep -R -i "error" /var/log 2> /dev/null | head

Check recent logs:

journalctl -p warning -n 100

If logs are huge, ask why.

Deleting logs may free space but hide the cause.

A safer approach is to archive, truncate if necessary and fix the underlying problem.

Working with journal and text logs together

Some systems use both traditional log files and systemd journal logs. You may need both.

For a service:

journalctl -u nginx -n 100

Traditional Nginx logs:

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/nginx/access.log

For SSH:

journalctl -u ssh -n 100

or:

sudo tail -n 100 /var/log/auth.log

For package operations:

cat /var/log/apt/history.log

and:

journalctl -u apt-daily.service

The exact logging location depends on the distribution, service and configuration.

A good habit is to check both service logs and application-specific logs.

Understanding system boot at a practical level

Boot is the process that starts the Linux system. You do not need to know every low-level detail at first, but you should understand the practical sequence.

A simplified boot flow:

On many modern systems, systemd manages services during boot.

Check boot logs:

journalctl -b

Check previous boot:

journalctl -b -1

List boots:

journalctl --list-boots

Check failed services after boot:

systemctl --failed

Check boot time summary:

systemd-analyze

Show slow services:

systemd-analyze blame

Show critical chain:

systemd-analyze critical-chain

This helps diagnose slow boot or services delaying startup.

Safety principles before changing the system

Administrative power is useful only when it is controlled. The safest Linux work happens when every edit, deletion, restart or installation is preceded by inspection and followed by verification.

Normal user privileges and sudo

Linux is designed around users and permissions. A normal user should be able to manage personal files but should not accidentally damage system files. Administrative changes require elevated privileges.

The most common way to run a command with administrative privileges is sudo.

sudo apt update

This means: run apt update as a superuser, if the current user is allowed to use sudo.

Common tasks that usually require sudo include installing software, editing system configuration, restarting system services, changing ownership of system files and mounting disks.

A dangerous beginner habit is using sudo for everything. That is not necessary and not safe. Use sudo only when the task requires it.

Compare these two commands:

rm notes.txt

This removes a file in the current directory if your user has permission.

sudo rm notes.txt

This removes it with elevated privileges. If you are in the wrong directory, the risk is higher.

The more power a command has, the more carefully it should be checked.

How to read command examples correctly

Many command examples use placeholders. A placeholder is not meant to be typed literally. It represents something you must replace.

Example:

cp  

You should not type and exactly. You replace them with real paths.

Correct example:

cp report.txt /home/pat/Documents/

Common placeholders include:

When you see:

ssh @

you should type something like:

ssh pat@192.168.1.10

Understanding placeholders prevents many beginner mistakes.

Your first safety workflow

Before learning many commands, learn this safety workflow:

pwd
ls -lah

This shows where you are and what is there.

Add one more command when working with directories:

tree -L 2

If tree is not installed, use:

find . -maxdepth 2

A safe inspection sequence is:

pwd
ls -lah
tree -L 2
du -sh .

This gives four layers of understanding.

This sequence does not modify anything. It is safe. It is also professional. Many serious mistakes happen because users act before inspecting.

The safest way to learn Linux commands

The safest way to learn Linux commands is to create a practice directory in your home folder and experiment there.

mkdir -p ~/linux-command-lab
cd ~/linux-command-lab
pwd

Inside this lab, create sample files:

mkdir documents logs scripts backups
touch documents/report.txt
touch logs/app.log
touch scripts/backup.sh

Display the structure:

tree

Expected structure:

.
├── backups
├── documents
│   └── report.txt
├── logs
│   └── app.log
└── scripts
    └── backup.sh

Now you can safely practice copying, moving, renaming, reading and deleting.

cp documents/report.txt backups/report-backup.txt
mv logs/app.log logs/application.log
ls -lah logs
tree

Remove practice files only after inspecting:

ls -lah backups
rm -i backups/report-backup.txt

This practice environment prevents damage to real files.

Remote administration safety habits

Remote Linux work requires extra caution because mistakes can affect systems you cannot physically access.

Use these habits:

A safe remote maintenance start:

ssh pat@server
hostname
whoami
uptime
df -h
systemctl --failed

A safe config edit pattern:

sudo cp /etc/service/config.conf /etc/service/config.conf.backup
sudo nano /etc/service/config.conf
sudo service-name --test-config
sudo systemctl reload service-name

The exact test command depends on the service.

Security notes for remote commands

Remote commands are powerful. They also carry risk.

Be especially careful with commands like:

ssh server "rm -rf /path"

or:

rsync -av --delete source/ server:/important/path/

Before destructive remote operations, run inspection commands.

ssh server "pwd; hostname; ls -lah /important/path"

For rsync, run:

rsync -av --delete --dry-run source/ server:/important/path/

For remote deletion, list first:

ssh server "find /path -type f -name '*.tmp' -mtime +30 -print"

Then delete only if correct:

ssh server "find /path -type f -name '*.tmp' -mtime +30 -delete"

A remote command should be treated with more caution than a local command because recovery may be harder.

Least privilege in practice

Least privilege means giving only the access required, not more.

Bad habit:

sudo chmod -R 777 /var/www/site

Better:

sudo find /var/www/site -type d -exec chmod 755 {} \;
sudo find /var/www/site -type f -exec chmod 644 {} \;

Then grant write access only where needed.

sudo chown -R www-data:www-data /var/www/site/uploads

Bad habit:

sudo chown -R www-data:www-data /var/www/site

This may make the web server own everything, including code files. If the application is compromised, an attacker may be able to modify application code more easily.

A better model may be:

There is no universal permission model for every application, but the principle is universal: do not give write access where read access is enough.

Dangerous commands and why they are dangerous

Some commands are not bad, but they are dangerous when used without context.

Before running dangerous commands, use a safety checklist.

hostname
whoami
pwd
ls -lah

For file deletion:

find /target/path -type f -name "*.tmp" -print

Then:

find /target/path -type f -name "*.tmp" -delete

For rsync --delete:

rsync -av --delete --dry-run source/ destination/

Then:

rsync -av --delete source/ destination/

For recursive ownership changes:

ls -ld /target/path
find /target/path -maxdepth 2 -exec ls -ld {} \; | head

Then apply only if correct.

A dangerous command should never be the first command in a workflow.

Operational discipline: one change at a time

When fixing a Linux problem, make one meaningful change at a time.

Bad workflow:

sudo chmod -R 777 /var/www/site
sudo chown -R www-data:www-data /var/www/site
sudo systemctl restart nginx
sudo apt upgrade

After this, if the problem is fixed or worse, you do not know which change mattered.

Better workflow:

systemctl status nginx
journalctl -u nginx -n 100
namei -l /var/www/site/index.html

Then one change:

sudo chmod 755 /var/www/site

Verify:

curl -I http://localhost

Then another change only if needed.

One change at a time makes troubleshooting learnable and reversible.

Operational discipline: save the exact command

When a command solves a problem, save it.

Create notes:

mkdir -p ~/ops/notes
nano ~/ops/notes/fixes.md

Add:

Problem:
Nginx failed because port 80 was already used.

Diagnosis:
sudo ss -tulpn | grep ':80'
sudo lsof -i :80

Fix:
sudo systemctl stop old-service
sudo systemctl restart nginx

Verification:
curl -I http://localhost
systemctl status nginx

This creates institutional memory, even if you are the only administrator.

Search later:

grep -i "port 80" ~/ops/notes/fixes.md

Linux knowledge grows faster when commands are documented in context.

Operational discipline: build command templates

Many Linux tasks repeat with small changes. Templates reduce mistakes.

Find large files template:

sudo find /PATH -type f -size +SIZE -exec ls -lh {} \;

Example:

sudo find /var/log -type f -size +100M -exec ls -lh {} \;

Rsync preview template:

rsync -avz --delete --dry-run SOURCE/ USER@HOST:DESTINATION/

Service diagnosis template:

systemctl status SERVICE
journalctl -u SERVICE -n 100
sudo ss -tulpn | grep PORT

Permission diagnosis template:

whoami
id
ls -l FILE
namei -l FILE

Backup template:

tar -czf NAME-$(date +%Y-%m-%d-%H-%M).tar.gz SOURCE
tar -tzf NAME-$(date +%Y-%m-%d-%H-%M).tar.gz | head

Templates are safer than rewriting complex commands from memory every time.

Navigation and inspection commands

Navigation and inspection commands answer the first operational questions: where am I, what is here and what does it look like?

pwd: know your current location

The command pwd means print working directory.

pwd

Example output:

/home/pat/projects

This tells you that your terminal is currently working inside /home/pat/projects.

The current directory matters because many commands operate relative to it.

If you type:

rm test.txt

Linux looks for test.txt in the current directory.

If you type:

cp report.txt backup/

Linux looks for report.txt and backup/ relative to where you are now.

This is why pwd should become automatic before file operations.

Use pwd before:

Example:

pwd
ls -lah
rm -i old-notes.txt

This is much safer than running rm blindly.

cd: move through the filesystem

The command cd means change directory.

Go to a specific absolute path:

cd /home/pat/Documents

Go to a directory relative to your current location:

cd Documents

Go to your home directory:

cd

or:

cd ~

Go to the root directory:

cd /

Go one level up:

cd ..

Go two levels up:

cd ../..

Return to the previous directory:

cd -

This command is useful when switching between two directories.

Example:

cd /var/log
pwd
cd /etc
pwd
cd -
pwd

The last cd - returns you to /var/log.

Understanding cd .. is essential. If you are in:

/home/pat/projects/linux/scripts

and run:

cd ..

you move to:

/home/pat/projects/linux

Run it again:

cd ..

Now you are in:

/home/pat/projects

Linux path navigation is logical once you think in levels.

Common cd mistakes

The cd command is simple, but beginners often run into predictable problems.

Handling spaces:

cd "My Folder"

or:

cd My\ Folder

The backslash tells the shell that the space belongs to the folder name.

However, for command-line work, names without spaces are usually easier.

Better:

my-folder
my_folder
project-backup

Less convenient:

My Folder
Project Backup Final
New Documents Copy

Spaces are allowed, but they require more care.

ls: list files and directories

The command ls lists directory contents.

Basic use:

ls

List a specific directory:

ls /home/pat/Documents

Long format:

ls -l

Show hidden files:

ls -a

Human-readable sizes:

ls -h

Common combined form:

ls -lah

This is one of the most useful commands in Linux.

A typical ls -lah output may look like this:

drwxr-xr-x  5 pat pat 4.0K May 14 10:20 .
drwxr-xr-x 25 pat pat 4.0K May 14 09:55 ..
-rw-r--r--  1 pat pat 1.2K May 14 10:18 notes.txt
-rwxr-xr-x  1 pat pat  842 May 14 10:19 backup.sh
drwxr-xr-x  2 pat pat 4.0K May 14 10:20 logs

This output contains a lot of information.

The first character tells you the type.

This means:

-rw-r--r--

is a regular file.

drwxr-xr-x

is a directory.

lrwxrwxrwx

is a symbolic link.

Understanding the first column of ls -l is the beginning of understanding Linux permissions.

Hidden files in Linux

In Linux, hidden files are not hidden through a special property. They are hidden because their names begin with a dot.

Examples:

.bashrc
.profile
.ssh
.config
.cache

The normal ls command does not show them.

ls

To show hidden files, use:

ls -a

To show hidden files with details and readable sizes:

ls -lah

Hidden files often store user configuration.

Do not delete hidden files casually. Some of them are important for login, shell behavior, SSH access or application settings.

Practical ls patterns

The ls command becomes more useful when you learn common patterns.

The command:

ls -ld /var/log

shows information about the directory /var/log itself.

The command:

ls -l /var/log

shows what is inside /var/log.

This difference matters when checking permissions on a directory.

tree: see the structure clearly

The command tree displays a directory structure visually.

tree

Example output:

.
├── documents
│   ├── report.txt
│   └── notes.txt
├── scripts
│   └── backup.sh
└── logs
    └── app.log

This is much easier to understand than a flat list when working with projects.

Show a specific directory:

tree /home/pat/projects

Limit depth:

tree -L 2

Show only directories:

tree -d

Show hidden files too:

tree -a

Show human-readable sizes:

tree -h

Combine options:

tree -a -h -L 2

If tree is not installed:

sudo apt update
sudo apt install tree

A useful alternative using find:

find . -maxdepth 2

This lists files and directories up to two levels below the current directory.

Creating, reading, copying, moving and deleting files

Most real Linux work begins with files. Creating, reading, editing, copying, moving, linking and deleting data should be done with enough context to avoid accidental damage.

mkdir: create directories

The command mkdir creates directories.

mkdir test

This creates a directory named test in the current location.

Create a directory using an absolute path:

mkdir /home/pat/test

Create multiple directories:

mkdir documents scripts backups

Create nested directories:

mkdir -p projects/linux/scripts

The -p option means create parent directories if they do not exist.

Without -p, this can fail:

mkdir projects/linux/scripts

if projects or projects/linux does not already exist.

With -p, Linux creates the full structure.

mkdir -p projects/linux/scripts

This is especially useful in scripts because it avoids errors when parent directories are missing.

Common mkdir examples:

The command mkdir -m sets permissions during creation.

mkdir -m 700 private

This creates a directory accessible only to the owner.

touch: create empty files and update timestamps

The command touch creates an empty file if the file does not exist.

touch notes.txt

If the file already exists, touch updates its modification timestamp.

Create multiple files:

touch file1.txt file2.txt file3.txt

Create a file in another directory:

touch /home/pat/Documents/notes.txt

Why use touch?

Example permission test:

touch /var/log/test-file

As a normal user, this will likely fail.

touch: cannot touch '/var/log/test-file': Permission denied

That tells you the directory is protected.

Inside your home directory, this should work:

touch ~/test-file

nano: edit text files from the terminal

The command nano opens a simple terminal text editor.

nano notes.txt

If notes.txt exists, nano opens it. If it does not exist, nano creates it when you save.

Open a file in another directory:

nano /home/pat/Documents/notes.txt

Edit a system file with administrative privileges:

sudo nano /etc/hosts

Important nano shortcuts:

A safe configuration editing workflow:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo nano /etc/ssh/sshd_config

This creates a backup before editing.

That habit is extremely important. Many Linux problems are caused by editing configuration files without keeping a known-good copy.

A practical rule: before editing an important file under /etc, make a backup first.

cat: display and concatenate files

The command cat displays file content.

cat notes.txt

It can also concatenate multiple files.

cat part1.txt part2.txt part3.txt

Save combined output to a new file:

cat part1.txt part2.txt part3.txt > complete.txt

Display all text files matching a pattern:

cat *.txt

The * character is a wildcard. It means any characters.

Use cat for short files. Do not use it blindly on huge logs because it can flood your terminal.

Good uses of cat:

Although this works:

cat app.log | grep error

this is usually simpler:

grep error app.log

Still, cat remains useful because it is easy to understand and often appears in examples and scripts.

more and less: read long files safely

The command more displays long files page by page.

more long-file.txt

Basic controls:

A more powerful alternative is less.

less long-file.txt

Despite the name, less is more capable than more.

Useful controls inside less:

Use less for logs, configuration files and command output that is too long for one screen.

Example:

less /var/log/syslog

Search inside it:

/error

Then press n to jump to the next match.

head: inspect the beginning of a file

The command head shows the first lines of a file.

head file.txt

By default, it shows the first 10 lines.

Show the first 20 lines:

head -n 20 file.txt

or:

head -20 file.txt

head is useful when you need to understand the structure of a file quickly.

Examples:

head /etc/passwd

head -n 5 data.csv

head -n 30 app.log

Common uses:

For example, before processing a CSV file with awk or cut, use:

head -n 3 data.csv

This helps you avoid wrong assumptions about delimiters and columns.

tail: inspect the end of a file

The command tail shows the last lines of a file.

tail file.txt

By default, it shows the last 10 lines.

Show the last 50 lines:

tail -n 50 file.txt

Follow a file in real time:

tail -f file.txt

This is one of the most important commands for Linux troubleshooting.

For example:

sudo tail -f /var/log/syslog

This shows new system log entries as they are written.

Another example:

sudo tail -f /var/log/auth.log

This can show authentication-related events on many Debian-based systems.

A practical service debugging workflow:

sudo systemctl restart apache2
sudo tail -f /var/log/apache2/error.log

This restarts Apache and then watches the error log.

Stop tail -f with:

Ctrl + C

Useful tail patterns:

cp: copy files and directories

The command cp copies files.

Basic copy:

cp source.txt target.txt

Copy a file into a directory:

cp report.txt /home/pat/Documents/

Copy and rename at the same time:

cp report.txt /home/pat/Documents/final-report.txt

Copy multiple files into a directory:

cp file1.txt file2.txt file3.txt /home/pat/Documents/

Copy a directory recursively:

cp -r project project-backup

The -r option means recursive. It copies a directory and everything inside it.

Important cp options:

Archive mode is often better for backups.

cp -a website website-backup

This preserves permissions, timestamps and symbolic links more carefully than a simple recursive copy.

A safe copy command:

cp -av project project-backup

This copies in archive mode and shows what is happening.

mv: move and rename files

The command mv moves or renames files and directories.

Rename a file:

mv oldname.txt newname.txt

Move a file:

mv report.txt /home/pat/Documents/

Move and rename at the same time:

mv report.txt /home/pat/Documents/final-report.txt

Rename a directory:

mv old-project new-project

Move a directory:

mv project /home/pat/backups/

Important options:

Safer move:

mv -iv draft.txt final.txt

Unlike cp, mv does not require -r for directories.

A practical difference:

Be careful when moving files across filesystems. Moving inside the same filesystem is usually very fast because Linux changes directory references. Moving across disks may require copying data and deleting the original.

rm: remove files and directories

The command rm removes files.

rm file.txt

Remove multiple files:

rm file1.txt file2.txt file3.txt

Ask before removing:

rm -i file.txt

Remove a directory recursively:

rm -r folder

Force deletion:

rm -f file.txt

Recursive forced deletion:

rm -rf folder

This is powerful and dangerous.

A safer beginner command is:

rm -ri folder

This removes recursively but asks for confirmation.

Before deleting a directory, inspect it:

pwd
ls -lah
du -sh folder
tree -L 2 folder

Then remove:

rm -ri folder

Do not run destructive commands copied from the internet unless you understand every part.

Especially dangerous patterns include:

rm -rf /
rm -rf *
rm -rf ./*
sudo rm -rf /path
find / -name "*.log" -exec rm {} \;

The command rm -rf * removes everything matching * in the current directory. If you are in the wrong place, the result can be disastrous.

A safer habit is to use ls first with the same pattern.

ls *.log
rm -i *.log

rmdir: remove empty directories

The command rmdir removes empty directories.

rmdir empty-folder

If the directory contains files, rmdir refuses to remove it.

rmdir: failed to remove 'folder': Directory not empty

This makes rmdir safer than rm -r, but less flexible.

Use rmdir when you specifically expect a directory to be empty. Use rm -r only when you intend to remove contents too.

Practical workflow: create, inspect, copy, move and remove files

The following workflow demonstrates basic file operations safely.

Create a practice directory:

mkdir -p ~/linux-practice
cd ~/linux-practice
pwd

Create files:

touch notes.txt tasks.txt log.txt
ls -lah

Write text into a file using redirection:

echo "Linux practice notes" > notes.txt
echo "First task" > tasks.txt
echo "Application started" > log.txt

Read files:

cat notes.txt
cat tasks.txt
cat log.txt

Copy a file:

cp notes.txt notes-copy.txt
ls -lah

Rename a file:

mv notes-copy.txt archived-notes.txt
ls -lah

Create a subdirectory:

mkdir archive

Move the archived file:

mv archived-notes.txt archive/
tree

Search text:

grep "Linux" notes.txt

Remove safely:

rm -i tasks.txt
rm -ri archive

This small exercise covers mkdir, cd, pwd, touch, ls, echo, redirection, cat, cp, mv, tree, grep and rm.

It is simple, but it mirrors real Linux work.

Practical workflow: safely clean a temporary directory

Temporary directories can grow. But cleaning them blindly can break running programs.

Inspect first:

du -sh /tmp
sudo find /tmp -type f -mtime +7 -exec ls -lh {} \;

If the list looks safe, remove files older than 7 days:

sudo find /tmp -type f -mtime +7 -delete

Remove empty directories:

sudo find /tmp -type d -empty -delete

This is more controlled than:

sudo rm -rf /tmp/*

The second command may remove files currently needed by applications.

A precise cleanup is better than a dramatic cleanup.

Practical workflow: use diff to compare files

The command diff compares files.

diff old.conf new.conf

Unified format:

diff -u old.conf new.conf

This is useful after configuration changes.

Workflow:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.before
sudo nano /etc/nginx/nginx.conf
diff -u /etc/nginx/nginx.conf.before /etc/nginx/nginx.conf

The output shows what changed.

This is a professional habit because it prevents accidental edits from going unnoticed.

File timestamps help reconstruct what happened

Linux files have timestamps. The most commonly visible one in ls -l is modification time.

ls -l file.txt

Show detailed timestamps with stat:

stat file.txt

Example fields:

Modification time changes when file content changes.

Change time changes when metadata changes, such as permissions or ownership.

This is useful in investigations.

Find recently modified files:

find /var/www/site -type f -mtime -1

Find files modified in the last 30 minutes:

find /var/www/site -type f -mmin -30

Sort files by modification time:

ls -lt

Oldest last or reversed:

ls -ltr

This helps answer: what changed recently?

stat gives exact file metadata

The command stat displays detailed file information.

stat file.txt

Example output includes size, blocks, permissions, UID, GID and timestamps.

Use it when ls -l is not enough.

Example:

stat /var/www/site/index.php

This can help compare files before and after deployment.

You can format output:

stat -c "%n %U %G %a %s" file.txt

This prints:

Example output:

file.txt pat pat 644 1200

This can be useful in scripts.

ln and symbolic links

A symbolic link is a file that points to another file or directory.

Create symbolic link:

ln -s /real/path/file.txt link-name

Example:

ln -s /var/www/releases/2026-05-14 /var/www/current

Now /var/www/current points to the release directory.

Show link:

ls -l /var/www/current

Output may look like:

current -> /var/www/releases/2026-05-14

Symbolic links are common in deployments, configuration management and shared paths.

Important distinction:

Symbolic links are easier to understand and more common for directories and deployments.

If a symbolic link breaks, it points to a target that no longer exists.

Check target:

readlink link-name

Resolve full path:

readlink -f link-name

Find symbolic links:

find . -type l

Find broken symbolic links:

find . -xtype l

Practical workflow: generate files from scripts

Create a simple configuration file:

cat > app.conf << 'EOF'
APP_ENV=production
APP_DEBUG=false
APP_PORT=8080
EOF

Create a protected file with sudo:

sudo tee /etc/myapp.conf > /dev/null << 'EOF'
APP_ENV=production
APP_DEBUG=false
APP_PORT=8080
EOF

Append a block:

cat >> notes.txt << 'EOF'
New section
More notes
EOF

This is useful for automation, but be careful. > overwrites. >> appends.

Before overwriting an important file, back it up.

Safe deletion with trash alternatives

The terminal rm command usually does not move files to a graphical trash bin. It deletes directory entries directly.

For safer interactive work, use:

rm -i file.txt

For recursive interactive deletion:

rm -ri directory

For a safer manual approach, move files to a temporary review directory first.

mkdir -p ~/delete-review
mv old-files ~/delete-review/

Inspect later:

ls -lah ~/delete-review

Delete only after review:

rm -ri ~/delete-review/old-files

This is useful when you are not completely sure.

For servers, deletion safety comes from backups, review commands and precise paths, not from a trash feature.

Practical workflow: cleanup with review directory

Suppose you want to remove old generated files from a project.

Create review folder:

mkdir -p ~/cleanup-review

Find files:

find /var/www/site/cache -type f -mtime +30 -exec ls -lh {} \;

Move instead of delete:

find /var/www/site/cache -type f -mtime +30 -exec mv {} ~/cleanup-review/ \;

Check application behavior. Check disk:

df -h
du -sh ~/cleanup-review

If everything is fine, delete later:

rm -ri ~/cleanup-review

This approach is slower but safer when you are uncertain.

For huge numbers of files, moving all into one directory may cause name collisions or performance issues. In that case, use a structured cleanup or direct deletion after proper backups. But the review-directory concept is useful for small and medium cleanup tasks.

Understanding diff and patch

The command diff shows differences between files.

diff -u old.conf new.conf

The -u option produces unified diff format, widely used in development and administration.

Save patch:

diff -u old.conf new.conf > change.patch

Apply patch:

patch old.conf < change.patch

In system administration, you may not use patch every day, but diff -u is extremely useful for reviewing configuration changes.

Example:

sudo cp /etc/ssh/sshd_config /tmp/sshd_config.before
sudo nano /etc/ssh/sshd_config
diff -u /tmp/sshd_config.before /etc/ssh/sshd_config

This shows exactly what changed before you reload SSH.

Practical workflow: review configuration changes before reload

Backup:

sudo cp /etc/nginx/nginx.conf /tmp/nginx.conf.before

Edit:

sudo nano /etc/nginx/nginx.conf

Review:

diff -u /tmp/nginx.conf.before /etc/nginx/nginx.conf

Test:

sudo nginx -t

Reload:

sudo systemctl reload nginx

Verify:

systemctl status nginx
journalctl -u nginx -n 50

This workflow is simple and professional.

Searching files, filtering text and processing output

Searching and text processing turn the terminal into an analytical tool. These commands find files, filter logs and extract meaning from structured text.

grep: search text with precision

The command grep searches for text patterns in files or command output.

Basic search:

grep "error" app.log

This displays every line in app.log that contains error.

Case-insensitive search:

grep -i "error" app.log

Show line numbers:

grep -n "error" app.log

Search recursively in a directory:

grep -r "database" /var/www/html

Ignore case recursively and show line numbers:

grep -rin "database" /var/www/html

Invert the search:

grep -v "Notice" app.log

This shows lines that do not contain Notice.

Count matching lines:

grep -c "error" app.log

Show filenames containing matches:

grep -l "error" *.log

Show context around matches:

grep -A 2 -B 4 "Fatal error" app.log

This shows two lines after and four lines before each matching line.

A powerful log example:

grep -i "failed password" /var/log/auth.log

Count failed password entries:

grep -i "failed password" /var/log/auth.log | wc -l

Show context:

grep -i -C 3 "failed password" /var/log/auth.log

This is how grep becomes a diagnostic tool.

Finding files is not only searching by name

One of the most important differences between a casual Linux user and a confident Linux user is the ability to find things precisely. On a graphical desktop, searching often means typing part of a filename into a search box. In the Linux command line, searching can be much more powerful. You can search by name, extension, type, size, modification time, ownership, permissions and even execute another command on every result.

The main command for this task is find.

find   

A simple example:

find /home/pat -iname "report.txt"

This searches inside /home/pat for a file or directory named report.txt, ignoring uppercase and lowercase differences.

The structure is logical.

The command find is not only useful when you have lost a file. It is also useful when auditing systems, cleaning old logs, locating large files, finding broken project structures, checking modified files after deployment and preparing backups.

A graphical search tool usually answers the question: “Where is this file?”

The find command can answer deeper questions:

The real value of find is not just that it searches. The real value is that it can search with conditions that matter to administrators.

Searching by filename with find

The most basic use of find is searching by filename.

find /home/pat -name "test.txt"

This searches inside /home/pat for an exact name match.

The -name option is case-sensitive. That means test.txt, Test.txt and TEST.txt are different.

To ignore case, use -iname.

find /home/pat -iname "test.txt"

This can match:

test.txt
Test.txt
TEST.txt

For beginners, -iname is often safer because real files are not always named consistently.

Search for all text files:

find /home/pat -iname "*.txt"

Search for all PHP files:

find /var/www -iname "*.php"

Search for all configuration files:

find /etc -iname "*.conf"

The * symbol is a wildcard. It means any characters.

Always quote patterns like "*.txt" when using find.

This is better:

find . -iname "*.txt"

This can behave unexpectedly:

find . -iname *.txt

The reason is that the shell may expand *.txt before find receives it. Quoting keeps the pattern intact.

Searching by file type

Linux directories can contain many kinds of filesystem objects: regular files, directories, symbolic links, devices, sockets and named pipes. When searching, you often want only one type.

Find only regular files:

find /home/pat -type f

Find only directories:

find /home/pat -type d

Find only symbolic links:

find /home/pat -type l

Combine type and name:

find /var/www -type f -iname "*.php"

This means: find only regular files under /var/www whose names end in .php.

Find directories named cache:

find /var/www -type d -iname "cache"

Find symbolic links:

find /usr/local/bin -type l

The -type filter is important because names alone can be misleading. A directory can be named backup.txt. A file can be named logs. Search by type when the distinction matters.

For most everyday work, f, d and l are the most common.

Searching by size

Disk space problems are common on Linux servers. A log grows unexpectedly. A backup script creates repeated archives. A user uploads large files. A database dump remains forgotten in a project directory. The find command helps locate files by size.

Find files larger than 100 MB:

find /home -type f -size +100M

Find files smaller than 1 KB:

find /home -type f -size -1k

Find files exactly 10 MB in size is less common, but possible:

find /home -type f -size 10M

The symbols matter.

A practical command for finding large files:

find /home -type f -size +500M -exec ls -lh {} \;

This finds files larger than 500 MB and displays them with readable sizes.

Explanation:

A more advanced version:

find /home -type f -size +500M -printf "%s %p\n" | sort -nr | head -20

This prints file sizes and paths, sorts them by size and shows the largest 20.

The lesson is important: when disk space is low, do not delete randomly. First locate the largest files.

Searching by modification time

Time-based searching is essential for administration. You may need to know which files changed recently, which logs are old, which backups should be removed or which files were modified after a deployment.

Find files modified in the last two days:

find /home -type f -mtime -2

Find files modified more than 30 days ago:

find /var/log -type f -mtime +30

Find files modified exactly around 7 days ago:

find /home -type f -mtime 7

The signs matter.

For minute-level precision, use -mmin.

Find files modified in the last 60 minutes:

find /home/pat -type f -mmin -60

Find files modified more than 120 minutes ago:

find /tmp -type f -mmin +120

This is very useful when troubleshooting.

Example: after updating a web application, find recently changed files:

find /var/www/html -type f -mmin -30

Example: find old compressed logs:

find /var/log -type f -iname "*.gz" -mtime +30

A safe cleanup workflow:

find /var/log -type f -iname "*.gz" -mtime +30

Review the output first. Then, only when you are sure:

sudo find /var/log -type f -iname "*.gz" -mtime +30 -delete

The order matters. Inspect first. Delete only after verification.

Running commands on find results

The find command becomes extremely powerful when combined with -exec. This allows you to run another command on every result.

Basic structure:

find   -exec  {} \;

The {} placeholder represents each found item.

Example:

find /var/log -iname "*.log.gz" -exec ls -lh {} \;

This lists each matching compressed log file.

Remove matching files:

find /var/log -iname "*.log.gz" -exec rm {} \;

This is powerful but dangerous.

A safer method is to print first:

find /var/log -iname "*.log.gz"

Then list with details:

find /var/log -iname "*.log.gz" -exec ls -lh {} \;

Then remove only if the result is correct:

sudo find /var/log -iname "*.log.gz" -exec rm {} \;

Another useful example: change permissions on all .sh scripts.

find ~/scripts -type f -iname "*.sh" -exec chmod +x {} \;

Compress old logs:

find /var/log/myapp -type f -iname "*.log" -mtime +7 -exec gzip {} \;

Copy all PDF files into one folder:

find ~/Documents -type f -iname "*.pdf" -exec cp {} ~/pdf-collection/ \;

The -exec feature can save hours, but it must be used carefully.

A professional habit is to replace the action with echo first.

find /var/log -iname "*.gz" -mtime +30 -exec echo rm {} \;

This prints what would be removed without actually removing it.

find with maxdepth and mindepth

By default, find searches recursively through all subdirectories. Sometimes this is too much.

Limit search to the current directory only:

find . -maxdepth 1 -type f

Search two levels deep:

find . -maxdepth 2 -type f

Ignore the current directory itself and search below it:

find . -mindepth 1 -type d

Combine both:

find . -mindepth 1 -maxdepth 2 -type d

This finds directories at depth one or two, but not the current directory itself.

This is useful when working with large projects or system folders where a full recursive search would produce too much output.

Example:

find /var/www -maxdepth 2 -type d

This shows the upper directory structure of web projects without descending into every subfolder.

Practical workflow: collect all files of one type

Suppose you want to collect all .pdf files from a large directory tree.

Create destination:

mkdir -p ~/pdf-collection

Preview files:

find ~/Documents -type f -iname "*.pdf"

Copy files:

find ~/Documents -type f -iname "*.pdf" -exec cp {} ~/pdf-collection/ \;

Check result:

ls -lah ~/pdf-collection

Count copied files:

find ~/pdf-collection -type f -iname "*.pdf" | wc -l

This workflow uses mkdir, find, cp, ls and wc together.

That is real command-line productivity.

Key takeaways

At this point, the command line becomes more than navigation and file reading. You now have the tools to search deeply, archive safely, analyze disk usage, mount filesystems and control permissions.

The most important commands in this section are:

The deeper lesson is this: Linux administration is a sequence of careful questions.

Where is the file? Use find.

How large is it? Use du or ls -lh.

Which filesystem is full? Use df.

Who owns it? Use ls -l.

Who can access it? Read the permissions.

Can it be executed? Check x.

Should it be archived? Use tar.

Should it be deleted? Inspect first, then act.

The more carefully you ask, the safer and more powerful your command line work becomes.

wc: counting lines, words, characters and bytes

The command wc means word count, but it can count more than words.

Basic use:

wc file.txt

Example output:

  20  150  900 file.txt

The columns usually mean:

Count lines only:

wc -l file.txt

Count words only:

wc -w file.txt

Count characters:

wc -m file.txt

Count bytes:

wc -c file.txt

wc is especially useful after pipes.

Count matching lines:

grep -i "error" app.log | wc -l

Count files found by find:

find /var/www -type f | wc -l

Count logged-in users:

who | wc -l

Count installed packages:

dpkg -l | wc -l

The command wc -l is one of the simplest ways to turn text output into a number.

cut: extracting columns from structured text

The command cut extracts parts of each line. It is useful when text is separated by delimiters such as colons, commas, tabs or spaces.

A classic example uses /etc/passwd.

cut -d : -f 1 /etc/passwd

This prints the first field of each line, using : as the delimiter.

Explanation:

The file /etc/passwd contains user account records. The first field is the username.

Extract usernames and home directories:

cut -d : -f 1,6 /etc/passwd

Extract only characters 1 to 10:

cut -c 1-10 file.txt

Extract the second column from a CSV file:

cut -d ',' -f 2 data.csv

Common options:

Example:

cut -d ',' -f 1,3 data.csv

This prints fields 1 and 3 from a comma-separated file.

cut is simple and fast, but it is not a complete CSV parser. Real CSV files can contain quoted commas, line breaks inside fields and escaping rules. For simple delimiter-based text, cut is excellent. For complex CSV, use more suitable tools.

awk: a complete text processing language

The command awk is more powerful than cut. It can select fields, apply conditions, calculate values, format output and behave like a small programming language.

Basic structure:

awk 'pattern { action }' file

Print the first field:

awk '{print $1}' file.txt

By default, awk splits input on whitespace.

Use a colon as field separator:

awk -F ':' '{print $1}' /etc/passwd

This prints usernames, similar to:

cut -d : -f 1 /etc/passwd

Print username and home directory:

awk -F ':' '{print $1, $6}' /etc/passwd

Print with custom formatting:

awk -F ':' '{print "User:", $1, "Home:", $6}' /etc/passwd

Print lines where the third field is greater than or equal to 1000:

awk -F ':' '$3 >= 1000 {print $1, $3}' /etc/passwd

This is already more powerful than cut.

Important awk field variables:

Print line numbers:

awk '{print NR, $0}' file.txt

Print last field:

awk '{print $NF}' file.txt

Print only lines with more than 5 fields:

awk 'NF > 5 {print $0}' file.txt

awk for log analysis

Suppose a web access log has lines where the first field is the client IP address. You can count requests by IP.

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

This means:

Print the first and ninth fields from a web log:

awk '{print $1, $9}' access.log

If the ninth field is HTTP status code, this can show which IP produced which status.

Count status codes:

awk '{print $9}' access.log | sort | uniq -c | sort -nr

Find lines with status 500:

awk '$9 == 500 {print $0}' access.log

Find IPs causing 404 errors:

awk '$9 == 404 {print $1}' access.log | sort | uniq -c | sort -nr | head

These are real server investigation patterns. They show why text processing is central to Linux administration.

awk for calculations

awk can also calculate.

Suppose sizes.txt contains numbers:

10
25
30

Sum them:

awk '{sum += $1} END {print sum}' sizes.txt

Output:

65

Average:

awk '{sum += $1; count++} END {print sum / count}' sizes.txt

Print total size from a command:

du -sk * | awk '{sum += $1} END {print sum " KB"}'

This is where awk becomes more than a column extractor. It becomes a compact data processing tool.

sed: editing text streams

The command sed is a stream editor. It reads text, applies editing rules and prints the result.

Basic substitution:

sed 's/old/new/' file.txt

This replaces the first occurrence of old with new on each line in the output. It does not modify the file unless you use in-place editing.

Replace all occurrences on each line:

sed 's/old/new/g' file.txt

The g means global within each line.

Delete lines beginning with #:

sed '/^#/d' config.conf

This removes comment lines from the output.

Delete empty lines:

sed '/^$/d' file.txt

Print only a range of lines:

sed -n '10,20p' file.txt

This prints lines 10 through 20.

In-place editing:

sed -i 's/old/new/g' file.txt

In-place editing with backup:

sed -i.backup 's/old/new/g' file.txt

This creates file.txt.backup.

The backup form is much safer when learning.

sed examples for configuration cleanup

Show a configuration file without comments and empty lines:

sed '/^#/d; /^$/d' config.conf

This applies two commands:

This is useful when reading long configuration files.

Example:

sed '/^#/d; /^$/d' /etc/ssh/sshd_config

Be careful: this prints a cleaned view. It does not show inline comments and it does not explain inherited defaults. Still, it can make large configuration files easier to inspect.

Replace a domain in a file:

sed -i.backup 's/old.example.com/new.example.com/g' config.conf

Then compare:

diff config.conf.backup config.conf

If wrong, restore:

mv config.conf.backup config.conf

A professional habit with sed -i is to make a backup first or use the built-in backup extension.

sort and uniq: organizing and counting text

The command sort sorts lines.

sort file.txt

Reverse sort:

sort -r file.txt

Numeric sort:

sort -n numbers.txt

Human-readable size sort:

sort -h sizes.txt

Sort by a specific column:

sort -k 2 file.txt

The command uniq removes adjacent duplicate lines.

uniq file.txt

Important detail: uniq only removes duplicates that are next to each other. This is why it is often used after sort.

sort file.txt | uniq

Count duplicates:

sort file.txt | uniq -c

Sort counts descending:

sort file.txt | uniq -c | sort -nr

This pattern is extremely useful.

Count repeated errors:

grep -i "error" app.log | sort | uniq -c | sort -nr

Count top IP addresses:

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

Count status codes:

awk '{print $9}' access.log | sort | uniq -c | sort -nr

The combination sort | uniq -c | sort -nr is one of the most practical Linux text-analysis patterns.

head and tail in pipelines

The commands head and tail are not only for reading files. They also limit pipeline output.

Show top 10 largest files from a du pipeline:

du -ak | sort -nr | head

Show top 20:

du -ak | sort -nr | head -20

Show the last 20 commands from history:

history | tail -n 20

Show the latest 50 matching log lines:

grep -i "error" app.log | tail -n 50

Show the first 5 users from /etc/passwd:

cut -d : -f 1 /etc/passwd | head -5

In real work, many commands produce too much output. head and tail help you inspect a manageable slice.

Practical workflow: analyze a large log file

Suppose you have a large application log named app.log.

Start by checking size:

ls -lh app.log

Inspect beginning:

head -n 20 app.log

Inspect end:

tail -n 50 app.log

Count total lines:

wc -l app.log

Count error lines:

grep -i "error" app.log | wc -l

Show most common error lines:

grep -i "error" app.log | sort | uniq -c | sort -nr | head -20

Save error summary:

grep -i "error" app.log | sort | uniq -c | sort -nr > error-summary.txt

Read summary:

less error-summary.txt

Follow new errors live:

tail -f app.log | grep -i "error"

This workflow turns a large log into useful information.

Practical workflow: count web requests by IP address

Assume access.log is a web access log where the first field is the client IP.

Top IP addresses:

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20

Count total requests:

wc -l access.log

Count unique IP addresses:

awk '{print $1}' access.log | sort -u | wc -l

Save top IP report:

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -50 > top-ips.txt

This is useful for traffic analysis, abuse detection, debugging and understanding server load.

Practical workflow: count HTTP status codes

If the ninth field in an access log is the HTTP status code, count status codes:

awk '{print $9}' access.log | sort | uniq -c | sort -nr

Find 500 errors:

awk '$9 == 500 {print $0}' access.log

Find 404 errors:

awk '$9 == 404 {print $0}' access.log

Top IPs causing 404 errors:

awk '$9 == 404 {print $1}' access.log | sort | uniq -c | sort -nr | head -20

Save 500 errors:

awk '$9 == 500 {print $0}' access.log > http-500-errors.log

A few commands can answer questions that would be tedious in a graphical editor.

Practical workflow: prepare a clean configuration view

Many configuration files contain comments and blank lines. To read active lines more easily:

sed '/^#/d; /^$/d' config.conf

For SSH configuration:

sudo sed '/^#/d; /^$/d' /etc/ssh/sshd_config

For Apache configuration:

sed '/^#/d; /^$/d' /etc/apache2/apache2.conf

This does not edit the file. It prints a cleaned view.

Save cleaned view:

sed '/^#/d; /^$/d' config.conf > active-config-view.txt

This is useful for review, documentation or troubleshooting.

Practical workflow: batch rename with shell tools

Suppose you have files ending in .jpeg and want to rename them to .jpg.

Preview:

ls *.jpeg

A simple loop:

for file in *.jpeg; do
    mv "$file" "${file%.jpeg}.jpg"
done

Explanation:

Safer preview:

for file in *.jpeg; do
    echo mv "$file" "${file%.jpeg}.jpg"
done

This prints the planned commands without running them.

Only after review, run the real loop.

This preview-first method is important for batch operations.

Practical workflow: find and process files safely

Find all .log files:

find . -type f -name "*.log"

Show sizes:

find . -type f -name "*.log" -exec ls -lh {} \;

Count them:

find . -type f -name "*.log" | wc -l

Compress logs older than 7 days:

find . -type f -name "*.log" -mtime +7 -exec gzip {} \;

Preview deletion of compressed logs older than 30 days:

find . -type f -name "*.gz" -mtime +30 -exec echo rm {} \;

Delete after verifying:

find . -type f -name "*.gz" -mtime +30 -delete

The important pattern is: find, inspect, count, preview, act.

Practical workflow: use grep, awk and cut together

Extract usernames from /etc/passwd:

cut -d : -f 1 /etc/passwd

Show users with UID 1000 or higher:

awk -F ':' '$3 >= 1000 {print $1, $3, $6}' /etc/passwd

Search for a specific shell:

grep "/bin/bash" /etc/passwd

Extract usernames using Bash shell:

grep "/bin/bash" /etc/passwd | cut -d : -f 1

This demonstrates tool selection:

The tools overlap, but each has a natural strength.

Practical workflow: create a top error report from a web log

Assume access.log contains web requests.

Create report:

{
    echo "Top client IPs"
    awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20

    echo
    echo "HTTP status code counts"
    awk '{print $9}' access.log | sort | uniq -c | sort -nr

    echo
    echo "Top 404 sources"
    awk '$9 == 404 {print $1}' access.log | sort | uniq -c | sort -nr | head -20

    echo
    echo "Recent 500 errors"
    awk '$9 == 500 {print $0}' access.log | tail -20
} > web-log-report.txt

Read it:

less web-log-report.txt

This is a compact reporting workflow using grouping, awk, sort, uniq, head, tail and redirection.

Time based log investigation

When investigating an incident, time matters.

Show logs since a specific time:

journalctl --since "2026-05-14 09:00"

Until a specific time:

journalctl --since "2026-05-14 09:00" --until "2026-05-14 10:00"

For a service:

journalctl -u nginx --since "2026-05-14 09:00" --until "2026-05-14 10:00"

For plain log files, use grep if timestamps are textual.

grep "2026-05-14 09:" app.log

Show files modified during the period:

find /var/www/site -type f -newermt "2026-05-14 09:00" ! -newermt "2026-05-14 10:00" -exec ls -lh {} \;

This command finds files modified between 09:00 and 10:00.

Time-based investigation is essential when a problem begins after a deployment, update, reboot or scheduled job.

Using find with newermt

The find command can search by human-readable modification time using -newermt.

Find files modified after a date:

find /var/www/site -type f -newermt "2026-05-14" -exec ls -lh {} \;

Find files modified after a specific time:

find /var/www/site -type f -newermt "2026-05-14 10:00" -exec ls -lh {} \;

Find files modified in a range:

find /var/www/site -type f -newermt "2026-05-14 10:00" ! -newermt "2026-05-14 11:00" -exec ls -lh {} \;

This is extremely useful after deployment incidents.

Example workflow:

find /etc -type f -newermt "2026-05-14 09:00" -exec ls -lh {} \;
find /var/www -type f -newermt "2026-05-14 09:00" -exec ls -lh {} \;
journalctl --since "2026-05-14 09:00"

This connects file changes and logs in the same time window.

Pipes, redirection and command composition

Pipes, redirection and shell interpretation explain why small commands can become complete workflows.

Understanding pipes

The pipe symbol | sends the output of one command into another command.

Example:

ls -lah | grep ".log"

This means:

Another example:

history | tail -n 20

This shows only the last 20 commands from your command history.

A more advanced example:

du -ak | sort -nr | head -20

This shows large files or directories.

Pipes are one of the most important concepts in Linux. They allow simple tools to become powerful workflows.

A command pipeline should be read from left to right. Each command transforms the previous output.

Output redirection

Redirection sends command output into files instead of showing it only on the screen.

Overwrite or create a file:

command > file.txt

Append to a file:

command >> file.txt

Example:

grep "error" app.log > errors.txt

This creates errors.txt with all matching lines. If the file already exists, it is overwritten.

Append instead:

grep "error" app.log >> errors.txt

This adds matching lines to the end of the file.

Example separating successful output from errors:

find /etc -name "*.conf" > found.txt 2> denied.txt

This saves found files into found.txt and permission errors into denied.txt.

Example saving both output and errors:

find /etc -name "*.conf" &> result.txt

Redirection is essential for logging, scripting and automation.

The shell is more than a place where commands are typed

The Linux shell is not only a command launcher. It is an environment that can remember commands, expand patterns, redirect output, connect programs, store variables, repeat work, run scripts and automate system behavior.

This is where Linux begins to feel different from a normal graphical operating system. In a graphical interface, you usually perform one action at a time. In the shell, you can describe a whole workflow as text. That workflow can be repeated, saved, scheduled, shared, inspected and improved.

A command such as this is useful:

grep -i "error" app.log

But the shell becomes much more powerful when commands are combined:

grep -i "error" app.log | sort | uniq -c | sort -nr > error-summary.txt

This single line searches for errors, sorts them, counts repeated lines, sorts by frequency and saves the result into a file.

That is not just command usage. That is text-based automation.

The shell gives you several major powers.

A beginner sees the shell as a blank screen. An experienced Linux user sees it as a programmable control surface.

Shell expansion explains many surprising behaviors

The shell often modifies your command before the command itself runs. This process is called expansion.

For example:

ls *.txt

The ls command may never receive the literal text *.txt. The shell first expands *.txt into matching filenames.

If the directory contains:

notes.txt
report.txt
tasks.txt

then the command becomes:

ls notes.txt report.txt tasks.txt

This is why wildcard behavior can surprise beginners.

Common shell patterns:

Examples:

ls *.log

ls file?.txt

ls backup-*

Before removing files with a wildcard, always preview.

Do not start with:

rm *.log

Start with:

ls *.log

Then use safer deletion:

rm -i *.log

Wildcards are powerful, but they expand before the command runs. That means a mistake in the pattern can affect many files.

Quoting changes how the shell interprets text

Quotes control expansion and word splitting.

Without quotes:

echo Hello World

The shell sees two separate words: Hello and World.

With quotes:

echo "Hello World"

The shell treats the text as one argument.

This matters with filenames that contain spaces.

Wrong:

cd My Folder

The shell sees two arguments: My and Folder.

Correct:

cd "My Folder"

or:

cd My\ Folder

Double quotes allow variable expansion.

NAME="Linux"
echo "Hello $NAME"

Output:

Hello Linux

Single quotes prevent variable expansion.

NAME="Linux"
echo 'Hello $NAME'

Output:

Hello $NAME

Comparison:

A strong shell habit is to quote variables.

Better:

cp "$SOURCE" "$DESTINATION"

Riskier:

cp $SOURCE $DESTINATION

If a variable contains spaces, the unquoted version can break.

Variables make commands reusable

A shell variable stores a value.

PROJECT="website"

Use it with $.

echo "$PROJECT"

Output:

website

A practical example:

SOURCE="/var/www/site"
DESTINATION="/home/pat/backups"
DATE=$(date +%Y-%m-%d)

Now create a backup:

tar -czf "$DESTINATION/site-$DATE.tar.gz" "$SOURCE"

This is easier to read and safer to modify than a long command with repeated paths.

Variables are especially useful in scripts.

#!/bin/bash

SOURCE="/var/www/site"
DESTINATION="/home/pat/backups"
DATE=$(date +%Y-%m-%d)
ARCHIVE="$DESTINATION/site-$DATE.tar.gz"

mkdir -p "$DESTINATION"
tar -czf "$ARCHIVE" "$SOURCE"

echo "Backup created: $ARCHIVE"

This script is simple, but it already shows real automation.

Important syntax detail: do not place spaces around = when assigning variables.

Correct:

NAME="Linux"

Wrong:

NAME = "Linux"

The second form does not assign a variable. The shell interprets it differently.

Command substitution uses command output inside another command

Command substitution runs a command and inserts its output into another command.

Modern syntax:

$(command)

Example:

echo "Today is $(date +%Y-%m-%d)"

Output:

Today is 2026-05-14

Create a dated backup:

tar -czf "project-$(date +%Y-%m-%d).tar.gz" project/

Create a log line with timestamp:

echo "$(date +"%Y-%m-%d %H:%M:%S") backup started" >> backup.log

Store command output in a variable:

DATE=$(date +%Y-%m-%d)
HOST=$(hostname)

Use them:

echo "Running on $HOST at $DATE"

Command substitution is one of the bridges between one-time commands and shell scripts.

Pipes turn commands into workflows

A pipe sends the output of one command into the input of another command.

command1 | command2

Example:

ps aux | grep nginx

This runs ps aux, then filters the output through grep nginx.

Another example:

cat app.log | grep -i error

This works, but the shorter form is usually better:

grep -i error app.log

Pipes become valuable when several tools are connected.

grep -i "error" app.log | sort | uniq -c | sort -nr

This means:

A disk usage pipeline:

du -ak | sort -nr | head -20

This means:

A process pipeline:

ps aux | sort -nrk 3 | head -10

This sorts processes by CPU usage and shows the top 10.

The pipe is central to Linux because it lets each command remain simple while allowing the workflow to be complex.

Redirection controls where output goes

Most commands have output. By default, normal output appears on the terminal. Errors also appear on the terminal, but technically they use a different stream.

Linux commonly uses three standard streams.

Redirect standard output into a file:

command > output.txt

Append standard output to a file:

command >> output.txt

Redirect errors:

command 2> errors.txt

Redirect output and errors to separate files:

command > output.txt 2> errors.txt

Redirect both output and errors to one file:

command > all.txt 2>&1

Modern shorthand in many shells:

command &> all.txt

Example:

find /etc -name "*.conf" > found.txt 2> denied.txt

This stores successful results in found.txt and permission errors in denied.txt.

Append errors to a log file:

command 2>> errors.log

Discard output:

command > /dev/null

Discard errors:

command 2> /dev/null

Discard everything:

command > /dev/null 2>&1

The special file /dev/null is a data sink. Anything written to it disappears.

Use /dev/null carefully. It is useful in scripts, but hiding errors can make troubleshooting harder.

Redirection and sudo can be confusing

A common beginner problem appears when writing to protected files.

This often fails:

sudo echo "test" > /etc/example.conf

Why? Because sudo applies to echo, but the redirection > is handled by your current shell before sudo writes the file. The shell itself may not have permission to write into /etc.

Use tee instead:

echo "test" | sudo tee /etc/example.conf

Append with tee -a:

echo "another line" | sudo tee -a /etc/example.conf

Hide tee output if needed:

echo "test" | sudo tee /etc/example.conf > /dev/null

This pattern is important for writing into protected files from command pipelines.

Examples:

echo "127.0.0.1 localtest" | sudo tee -a /etc/hosts

printf "Hello\nWorld\n" | sudo tee /opt/example.txt

The core lesson: sudo does not automatically apply to shell redirection.

xargs converts input into command arguments

The command xargs takes input lines and turns them into arguments for another command.

A simple example:

find . -name "*.tmp" | xargs rm

This finds .tmp files and passes them to rm.

However, this can break when filenames contain spaces or unusual characters. A safer version uses null-separated output.

find . -name "*.tmp" -print0 | xargs -0 rm

Explanation:

Preview before deleting:

find . -name "*.tmp" -print0 | xargs -0 ls -lh

Then remove:

find . -name "*.tmp" -print0 | xargs -0 rm

Another example: count lines in all .log files.

find . -name "*.log" -print0 | xargs -0 wc -l

The command xargs is useful, but it should be handled carefully. For many tasks, find -exec is easier to read.

Compare:

find . -name "*.tmp" -exec rm {} \;

and:

find . -name "*.tmp" -print0 | xargs -0 rm

Both can work. xargs may be more efficient for large numbers of files because it can pass many files to one command invocation.

tee: display output and save it at the same time

The command tee reads input and writes it both to the screen and to a file.

command | tee output.txt

Example:

ls -lah | tee listing.txt

This displays the listing and saves it to listing.txt.

Append instead of overwrite:

command | tee -a output.txt

Use with protected files:

echo "example" | sudo tee /etc/example.conf

Use in logs:

sudo apt update | tee apt-update.log

Save both output and errors:

command 2>&1 | tee command.log

Example:

sudo apt upgrade 2>&1 | tee upgrade.log

This is useful during maintenance because you can watch output and keep a record.

Understanding standard input in practical commands

Standard input is the data a command reads. Many commands can read from files or from standard input.

Example:

cat file.txt

The file is an argument.

But this uses standard input:

cat < file.txt

Pipes provide standard input:

cat file.txt | grep error

Here, grep reads from standard input.

Equivalent:

grep error file.txt

Some commands are commonly used with standard input.

sort < names.txt

or:

cat names.txt | sort

A here-document sends standard input:

cat << 'EOF'
Line one
Line two
EOF

Understanding input makes pipes and scripts easier to reason about.

Understanding shell globbing versus find

Globbing is expansion performed by the shell.

ls *.log

This matches files in the current directory.

find searches recursively and with conditions.

find . -type f -name "*.log"

Comparison:

Use globbing for simple current-directory tasks.

ls *.txt
rm -i *.tmp

Use find for deeper controlled searches.

find /var/log -type f -name "*.gz" -mtime +30 -exec ls -lh {} \;

Argument list too long

Sometimes shell expansion creates too many arguments.

Example:

rm *.log

If there are too many .log files, you may see:

Argument list too long

This happens because the shell expands *.log into a huge list before running rm.

Use find instead:

find . -type f -name "*.log" -delete

Or interactive:

find . -type f -name "*.log" -exec rm -i {} \;

Or with xargs safely:

find . -type f -name "*.log" -print0 | xargs -0 rm

This is another reason find is essential for serious file operations.

Archives, compression and backup basics

Archives, compression and backups connect file operations with operational safety. A useful archive is not only created, but also inspected, moved, verified and restorable.

Archiving and compression in Linux

Linux systems often use archives for backups, transfers, deployments and log storage. The most important command is tar.

The name originally meant tape archive, but today it is used for packaging files and directories into archive files.

There is an important distinction:

The command tar can create an archive and optionally compress it.

Common archive extensions:

A .tar.gz file is extremely common in Linux.

Creating tar archives

Create a gzip-compressed tar archive:

tar -czvf archive.tar.gz /home/pat/project

This command creates archive.tar.gz from /home/pat/project.

The options can be understood like this:

The -f option must be followed by the archive filename.

This is correct:

tar -czvf project-backup.tar.gz project/

This is wrong or confusing:

tar -czv project-backup.tar.gz project/

Without -f, tar does not know that project-backup.tar.gz is the archive file name in the intended way.

A quieter version without verbose output:

tar -czf project-backup.tar.gz project/

For scripts, less verbose output is often preferred.

Create an uncompressed tar archive:

tar -cf archive.tar project/

Create a bzip2-compressed archive:

tar -cjvf archive.tar.bz2 project/

Create an xz-compressed archive:

tar -cJvf archive.tar.xz project/

For most practical use, .tar.gz is a safe default.

Extracting tar archives

Extract a .tar.gz archive:

tar -xzvf archive.tar.gz

Options:

A quieter version:

tar -xzf archive.tar.gz

Extract into a specific directory:

tar -xzf archive.tar.gz -C /home/pat/extracted

The destination directory must already exist.

mkdir -p /home/pat/extracted
tar -xzf archive.tar.gz -C /home/pat/extracted

List archive contents without extracting:

tar -tzf archive.tar.gz

This is a very important safety command.

Before extracting an archive from an unknown source, inspect its structure:

tar -tzf archive.tar.gz | head

Why this matters:

Some archives contain a clean folder like this:

project/
project/index.php
project/assets/style.css

Others may contain files directly:

index.php
style.css
config.php

If you extract the second type in the wrong directory, it can scatter files everywhere.

A safe extraction workflow:

mkdir -p ~/extract-test
tar -tzf archive.tar.gz | head -50
tar -xzf archive.tar.gz -C ~/extract-test

ZIP and unzip

ZIP files are common when exchanging files with Windows users, clients, designers, office workers or web platforms.

Create a ZIP archive:

zip archive.zip file1.txt file2.txt

Create a ZIP archive from a directory:

zip -r archive.zip project/

The -r option means recursive.

Extract a ZIP archive:

unzip archive.zip

Extract into a specific directory:

unzip archive.zip -d extracted/

List ZIP contents without extracting:

unzip -l archive.zip

This is the ZIP equivalent of inspecting before extracting.

Common ZIP workflow:

unzip -l website-files.zip
mkdir -p website-files
unzip website-files.zip -d website-files

Comparison between tar.gz and ZIP:

For Linux system backups, prefer tar.gz. For general file sharing, ZIP is often more convenient.

Practical archive workflow for backups

A good backup archive should have a clear name, include the correct directory and be easy to inspect.

Create a timestamped backup:

tar -czf project-$(date +%Y-%m-%d).tar.gz project/

If today is 2026-05-14, this creates:

project-2026-05-14.tar.gz

The date command inside $() runs first and inserts the result into the filename.

A more detailed timestamp:

tar -czf project-$(date +%Y-%m-%d-%H-%M).tar.gz project/

This may create:

project-2026-05-14-10-30.tar.gz

Backup and verify:

tar -czf project-backup.tar.gz project/
tar -tzf project-backup.tar.gz | head -20
ls -lh project-backup.tar.gz

This creates the archive, lists the first 20 archive entries and shows the archive size.

A safer backup script pattern:

#!/bin/bash

SOURCE="/home/pat/project"
DESTINATION="/home/pat/backups"
DATE=$(date +%Y-%m-%d-%H-%M)
ARCHIVE="$DESTINATION/project-$DATE.tar.gz"

mkdir -p "$DESTINATION"
tar -czf "$ARCHIVE" "$SOURCE"
tar -tzf "$ARCHIVE" > /dev/null

echo "Backup created: $ARCHIVE"

This simple script introduces several important Linux ideas: variables, quoting, directory creation, archive creation and verification.

Practical workflow: prepare a clean project backup

Suppose you want to back up a project directory.

Go to the parent directory:

cd /home/pat/projects
pwd
ls -lah

Inspect the project:

du -sh myproject
tree -L 2 myproject

Create a backup directory:

mkdir -p /home/pat/backups

Create a dated archive:

tar -czf /home/pat/backups/myproject-$(date +%Y-%m-%d).tar.gz myproject/

Verify archive exists:

ls -lh /home/pat/backups

Inspect archive contents:

tar -tzf /home/pat/backups/myproject-$(date +%Y-%m-%d).tar.gz | head -30

This is much better than simply compressing files blindly.

A backup is not complete until you know it can be read.

Practical workflow: securely copy a backup from a server

Suppose you want to download a backup from a server.

First connect and inspect:

ssh pat@server
hostname
ls -lh /home/pat/backups

Exit remote session:

exit

Download with scp:

scp pat@server:/home/pat/backups/project-backup.tar.gz .

Verify local file:

ls -lh project-backup.tar.gz
tar -tzf project-backup.tar.gz | head -30

A better method for large or repeated backups:

rsync -avz --progress pat@server:/home/pat/backups/ ./backups/

This preserves metadata and is efficient if run repeatedly.

Downloading and verifying archives

When downloading files with wget, do not immediately extract them into important directories.

Use a controlled directory:

mkdir -p ~/downloads
cd ~/downloads

Download:

wget https://example.com/archive.tar.gz

Check size:

ls -lh archive.tar.gz

Inspect archive:

tar -tzf archive.tar.gz | head -50

Create extraction directory:

mkdir -p extracted

Extract there:

tar -xzf archive.tar.gz -C extracted

Inspect:

tree -L 2 extracted

This prevents messy extraction into the wrong location.

For ZIP:

unzip -l archive.zip
mkdir -p extracted
unzip archive.zip -d extracted

The principle is the same: inspect before extracting.

Practical cron workflow for a daily backup

Create directories:

mkdir -p /home/pat/scripts
mkdir -p /home/pat/backups
mkdir -p /home/pat/logs

Create script:

nano /home/pat/scripts/site-backup.sh

Script content:

#!/bin/bash

SOURCE="/var/www/site"
DESTINATION="/home/pat/backups"
LOG="/home/pat/logs/site-backup.log"
DATE=$(date +%Y-%m-%d-%H-%M)
ARCHIVE="$DESTINATION/site-$DATE.tar.gz"

echo "$(date +"%Y-%m-%d %H:%M:%S") Backup started" >> "$LOG"

mkdir -p "$DESTINATION"

tar -czf "$ARCHIVE" "$SOURCE" >> "$LOG" 2>&1

if tar -tzf "$ARCHIVE" > /dev/null 2>&1; then
    echo "$(date +"%Y-%m-%d %H:%M:%S") Backup verified: $ARCHIVE" >> "$LOG"
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") Backup verification failed: $ARCHIVE" >> "$LOG"
    exit 1
fi

echo "$(date +"%Y-%m-%d %H:%M:%S") Backup finished" >> "$LOG"

Make executable:

chmod +x /home/pat/scripts/site-backup.sh

Run manually:

/home/pat/scripts/site-backup.sh

Check log:

tail -n 50 /home/pat/logs/site-backup.log

Edit crontab:

crontab -e

Add daily schedule:

0 2 * * * /home/pat/scripts/site-backup.sh

Verify:

crontab -l

This is a complete beginner-friendly automation workflow.

Practical workflow: create a compressed report bundle

Suppose support asks you for logs and system state.

Create report directory:

mkdir -p ~/support-report

Collect system information:

hostname > ~/support-report/hostname.txt
uptime > ~/support-report/uptime.txt
df -h > ~/support-report/disk.txt
ip a > ~/support-report/ip-addresses.txt
ip route > ~/support-report/routes.txt
systemctl --failed > ~/support-report/failed-services.txt

Collect recent logs:

journalctl -n 300 > ~/support-report/journal-recent.txt

Create archive:

tar -czf support-report-$(date +%Y-%m-%d-%H-%M).tar.gz support-report/

Inspect archive:

tar -tzf support-report-$(date +%Y-%m-%d-%H-%M).tar.gz | head -50

This creates a clean diagnostic package without manually copying terminal output.

Be careful not to include secrets, private keys, tokens or sensitive customer data in support bundles.

Practical workflow: investigate a broken backup

A backup file exists, but is it usable?

Check size:

ls -lh backup.tar.gz

Test archive listing:

tar -tzf backup.tar.gz > /dev/null

Check exit status:

echo $?

Show first entries:

tar -tzf backup.tar.gz | head -30

Extract to a test directory:

mkdir -p /tmp/restore-test
tar -xzf backup.tar.gz -C /tmp/restore-test
tree -L 2 /tmp/restore-test

A backup is not proven by existing. It is proven by successful reading and preferably test restoration.

A better backup script verifies after creation:

if tar -tzf "$ARCHIVE" > /dev/null 2>&1; then
    echo "Backup verified"
else
    echo "Backup failed verification"
    exit 1
fi

Working with compressed logs

Linux logs are often compressed after rotation.

You may see files like:

syslog.1
syslog.2.gz
auth.log.1
auth.log.2.gz

To read a .gz file without extracting it, use zcat.

zcat /var/log/syslog.2.gz | less

Search compressed logs with zgrep.

zgrep -i "error" /var/log/syslog.2.gz

Count matches:

zgrep -i "failed password" /var/log/auth.log.*.gz | wc -l

List compressed log contents:

gzip -l /var/log/syslog.2.gz

These tools help investigate older logs without manually decompressing files.

Practical workflow: create a pre change snapshot using tar

Before making risky changes to a directory, create a local archive.

sudo tar -czf /root/site-before-change-$(date +%Y-%m-%d-%H-%M).tar.gz /var/www/site

Verify:

sudo tar -tzf /root/site-before-change-$(date +%Y-%m-%d-%H-%M).tar.gz | head

For configuration:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%Y-%m-%d-%H-%M).backup

For whole config directory:

sudo tar -czf /root/nginx-config-before-change-$(date +%Y-%m-%d-%H-%M).tar.gz /etc/nginx

This provides rollback material before experiments.

A rollback archive is not a full backup strategy, but it is very useful before local changes.

Understanding file integrity checks

Sometimes you need to verify whether a file changed or whether two files are identical.

Use checksums.

sha256sum file.txt

Example output:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  file.txt

Compare two files:

sha256sum file1.txt file2.txt

If the hash is the same, the content is the same with extremely high practical confidence.

Create checksum file:

sha256sum backup.tar.gz > backup.tar.gz.sha256

Verify later:

sha256sum -c backup.tar.gz.sha256

This is useful for backups, downloads and file transfer verification.

For a directory archive:

tar -czf site.tar.gz /var/www/site
sha256sum site.tar.gz > site.tar.gz.sha256

After transfer:

sha256sum -c site.tar.gz.sha256

This verifies that the archive did not change during transfer.

Practical workflow: verify transferred backup

On source server:

tar -czf site-backup.tar.gz /var/www/site
sha256sum site-backup.tar.gz > site-backup.tar.gz.sha256

Transfer:

scp site-backup.tar.gz site-backup.tar.gz.sha256 backup@backup-server:/backups/

On backup server:

cd /backups
sha256sum -c site-backup.tar.gz.sha256

Expected output:

site-backup.tar.gz: OK

Then test archive:

tar -tzf site-backup.tar.gz | head

This workflow verifies both transfer integrity and archive readability.

Understanding compression choices

Different compression tools have different tradeoffs.

Create gzip tar:

tar -czf archive.tar.gz directory/

Create xz tar:

tar -cJf archive.tar.xz directory/

Create uncompressed tar:

tar -cf archive.tar directory/

If speed matters, gzip is often a good default. If smallest size matters and time is acceptable, xz may be useful.

For system backups, compatibility and restore speed often matter more than maximum compression.

Practical workflow: choose backup compression

Fast backup:

tar -czf site-fast-backup.tar.gz /var/www/site

Smaller backup:

tar -cJf site-small-backup.tar.xz /var/www/site

No compression, useful when storage is fast and compression is unnecessary:

tar -cf site-backup.tar /var/www/site

Check sizes:

ls -lh site-fast-backup.tar.gz site-small-backup.tar.xz site-backup.tar

Test readability:

tar -tf site-backup.tar | head
tar -tzf site-fast-backup.tar.gz | head
tar -tJf site-small-backup.tar.xz | head

Use the compression method that fits the operational need.

Practical workflow: restore configuration safely

Suppose you backed up /etc/nginx.

Archive:

nginx-config-backup.tar.gz

Inspect:

tar -tzf nginx-config-backup.tar.gz | head -50

Extract into test directory:

mkdir -p /tmp/nginx-config-restore
tar -xzf nginx-config-backup.tar.gz -C /tmp/nginx-config-restore
tree -L 3 /tmp/nginx-config-restore

Compare current and backup:

diff -ru /etc/nginx /tmp/nginx-config-restore/etc/nginx

Restore one file if needed:

sudo cp /tmp/nginx-config-restore/etc/nginx/nginx.conf /etc/nginx/nginx.conf

Test:

sudo nginx -t

Reload:

sudo systemctl reload nginx

This avoids blindly overwriting the whole configuration directory.

Practical workflow: compare cron and systemd timer for backups

Cron version:

0 2 * * * /home/pat/ops/scripts/site-backup >> /home/pat/ops/logs/site-backup-cron.log 2>&1

Systemd timer version:

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

Comparison:

Use cron for simple user tasks. Use systemd timers when you want service-style visibility, missed-run handling and better integration.

Permissions, ownership, users and groups

Permissions and ownership explain many Linux problems that look mysterious at first. Users, groups, modes, ACLs and sudo policy determine who can access what and under which conditions.

Understanding Linux permissions

Linux permissions control who can read, write and execute files. This is one of the most important security concepts in the system.

Run:

ls -l

Example:

-rw-r--r-- 1 pat pat 1200 May 14 10:18 notes.txt
-rwxr-xr-x 1 pat pat  842 May 14 10:19 backup.sh
drwxr-xr-x 2 pat pat 4096 May 14 10:20 scripts

The first column contains type and permissions.

Take this example:

-rwxr-xr--

Break it down:

The permission letters mean:

The meaning of execute permission is different for files and directories.

For a file, execute means you can run it as a program or script.

For a directory, execute means you can enter it and access items inside it if you know their names.

This is why directory permissions can be confusing. A directory needs execute permission to be usable.

Permission groups: owner, group and others

Every file has three permission categories.

Example:

-rw-r--r-- 1 pat editors 1200 May 14 10:18 article.txt

This means:

So pat can read and write. Members of editors can read. Everyone else can read.

A more restrictive example:

-rw------- 1 pat pat 1200 May 14 10:18 private.txt

Only pat can read and write this file.

A script example:

-rwxr-xr-x 1 pat pat 842 May 14 10:19 backup.sh

The owner can read, write and execute. Group and others can read and execute.

chmod with symbolic permissions

The command chmod changes permissions.

Make a script executable:

chmod +x backup.sh

This adds execute permission.

Remove execute permission:

chmod -x backup.sh

Give the owner execute permission only:

chmod u+x backup.sh

Remove write permission from others:

chmod o-w file.txt

Add read permission for group:

chmod g+r file.txt

The symbolic categories are:

The operations are:

The permissions are:

Examples:

chmod u+rw file.txt
chmod g-w file.txt
chmod o-r file.txt
chmod a+r public.txt
chmod u=rwx,g=rx,o= script.sh

Symbolic permissions are readable and good for learning.

chmod with numeric permissions

Numeric permissions are compact and common in administration.

Each permission has a number:

Add the numbers together.

A numeric permission has three digits.

Examples:

Set file to 644:

chmod 644 file.txt

Set script to 755:

chmod 755 script.sh

Set private key to 600:

chmod 600 ~/.ssh/id_rsa

Set private directory to 700:

chmod 700 ~/.ssh

Important warning: do not use chmod 777 as a universal fix. It gives everyone full access and can create serious security problems.

chmod on directories

Directory permissions deserve special attention.

For directories:

A common directory permission is 755.

chmod 755 public-directory

This means:

A private directory often uses 700.

chmod 700 private-directory

This means only the owner can access it.

For web directories, permissions must be chosen carefully. Giving write access to the wrong user can create security risks. Giving too little access can break uploads, cache generation or application updates.

A common safe starting pattern for many web projects is:

find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

This sets directories to 755 and files to 644.

Do not apply this blindly to every application. Some applications need writable cache or upload directories.

chown: change owner and group

The command chown changes file owner and group.

Change owner:

sudo chown pat file.txt

Change owner and group:

sudo chown pat:www-data file.txt

Change ownership recursively:

sudo chown -R pat:www-data /var/www/site

The -R option means recursive. It changes ownership for the directory and everything inside it.

This is powerful and must be used carefully.

Common ownership examples:

Check ownership:

ls -l file.txt

Check directory ownership:

ls -ld folder

The difference matters:

ls -l folder

shows the contents of the folder.

ls -ld folder

shows the folder itself.

Permission and ownership troubleshooting

Permission problems are common. The error messages usually look like this:

Permission denied

or:

Operation not permitted

A good troubleshooting workflow:

whoami
pwd
ls -ld .
ls -l target-file

This tells you who you are, where you are, the permissions of the current directory and the permissions of the target file.

If a script will not run:

ls -l script.sh
chmod +x script.sh
./script.sh

If a directory cannot be entered:

ls -ld directory

Check whether execute permission exists.

If a web application cannot write to a cache directory:

ls -ld cache
ls -l cache

You may need to adjust owner, group or permissions depending on which user the web server runs as.

For example:

sudo chown -R www-data:www-data cache

or:

sudo chmod -R 775 cache

But do not guess. First identify the correct service user.

ps aux | grep apache
ps aux | grep nginx

Permission fixes should be precise, not random.

The danger of recursive chmod and chown

Recursive permission changes can affect thousands of files.

This command:

sudo chmod -R 777 /var/www/site

may appear to “fix” a permission problem, but it creates a major security problem.

This command:

sudo chown -R pat:pat /

would be catastrophic because it would attempt to change ownership across the entire filesystem.

Before recursive changes, always verify the target.

pwd
ls -ld /var/www/site

Then use precise commands.

A safer web project example:

sudo find /var/www/site -type d -exec chmod 755 {} \;
sudo find /var/www/site -type f -exec chmod 644 {} \;

Writable upload directory only:

sudo chown -R www-data:www-data /var/www/site/uploads
sudo chmod -R 775 /var/www/site/uploads

This is better than making the entire website writable.

The principle is simple: change the smallest necessary area with the least necessary permission.

whoami, id and groups

Before changing permissions or debugging access, know who you are.

whoami

This prints the current username.

Show user and group IDs:

id

Example:

uid=1000(pat) gid=1000(pat) groups=1000(pat),27(sudo),33(www-data)

This tells you:

Show groups:

groups

Show groups for another user:

groups username

This matters because Linux permissions depend not only on the username but also on group membership.

If a file is owned by group www-data and has group write permission, a user must be in the www-data group to use that permission.

Example:

ls -l file.txt

Output:

-rw-rw-r-- 1 root www-data 1200 May 14 10:20 file.txt

A user in group www-data may write to this file if directory permissions also allow access.

Check:

id

If www-data is not listed, group permission will not apply to you.

su and sudo are different

The command sudo runs a command with elevated privileges, usually as root.

sudo apt update

The command su switches user.

su -

This tries to switch to the root user and start a login shell.

Switch to another user:

su - username

Run a command as another user with sudo:

sudo -u www-data whoami

Example:

sudo -u www-data php script.php

This runs the PHP script as the www-data user.

This is useful when debugging web application permissions. A file may be readable by your user but not by the web server user.

Test access as www-data:

sudo -u www-data ls -lah /var/www/site

Test writing:

sudo -u www-data touch /var/www/site/cache/test-file

If that fails, the web server may also fail to write cache files.

Use sudo -u as a diagnostic tool, not only as an administration shortcut.

Understanding users and groups in file access

Linux file access is decided by user, group and others permissions.

Example:

-rw-r----- 1 root www-data 1200 May 14 10:20 config.php

This means:

If the web server runs as www-data, it can read the file. Other users cannot.

Now consider:

drwxr-x--- 2 root www-data 4096 May 14 10:20 private

This directory allows:

If a user is not root and not in www-data, they cannot enter.

To troubleshoot path access, use:

namei -l /var/www/site/private/config.php

This shows permissions for every path component.

Example output may show:

drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-x--- root www-data site
-rw-r----- root www-data config.php

This helps reveal where access is blocked.

A file can have correct permissions, but if a parent directory blocks execute access, the file is still inaccessible.

passwd and changing passwords

The command passwd changes a user password.

Change your own password:

passwd

Change another user’s password as administrator:

sudo passwd username

Lock a password for an account:

sudo passwd -l username

Unlock:

sudo passwd -u username

On servers using SSH keys, password login may be disabled, but account passwords can still matter for local login, sudo policies or recovery workflows depending on configuration.

Password changes should be handled carefully, especially on production systems. Always know whether the account is used by humans, services or automation.

adduser, usermod and group membership

Create a user on Debian-based systems:

sudo adduser newuser

Add a user to a group:

sudo usermod -aG groupname username

Example: add user to sudo group:

sudo usermod -aG sudo pat

Example: add user to www-data group:

sudo usermod -aG www-data pat

The -aG combination is important.

Without -a, you may replace the user’s supplementary groups instead of adding to them. That can remove important access.

After group changes, the user usually needs to log out and log back in for the new group membership to appear.

Check:

id pat

or:

groups pat

Practical workflow: investigate permission denied

Suppose a user cannot read:

/var/www/site/uploads/image.jpg

Start with identity:

whoami
id

Check the file:

ls -l /var/www/site/uploads/image.jpg

Check the parent directory:

ls -ld /var/www/site/uploads

Check the whole path:

namei -l /var/www/site/uploads/image.jpg

Test as the service user if relevant:

sudo -u www-data ls -l /var/www/site/uploads/image.jpg

If the issue is missing directory execute permission, changing only the file will not help. One of the parent directories must allow traversal.

Example fix for a web upload directory:

sudo chown -R www-data:www-data /var/www/site/uploads
sudo find /var/www/site/uploads -type d -exec chmod 755 {} \;
sudo find /var/www/site/uploads -type f -exec chmod 644 {} \;

But this is only correct if www-data should own those uploads. Do not apply ownership changes blindly.

Process ownership and service users

Every process runs as a user. That user controls what the process can read and write.

Show processes:

ps aux

Find web server processes:

ps aux | grep nginx
ps aux | grep apache
ps aux | grep php

The first column is the process owner.

Example:

www-data  842  0.1  1.5 300000 65000 ?  S  10:20  0:01 nginx

This means the process runs as www-data.

If the process needs to write to:

/var/www/site/cache

then test:

sudo -u www-data touch /var/www/site/cache/test-file

If it fails, the application will likely fail too.

This is the connection between processes and permissions.

Advanced permissions explain many problems that basic chmod does not solve

Basic Linux permissions are built around three actions and three identity classes.

The actions are read, write and execute. The identity classes are owner, group and others. This model explains many everyday problems, but real Linux systems often need more detail. Web servers, shared directories, deployment users, backup users, scripts, SSH keys and service accounts all depend on permissions behaving predictably.

A beginner may know that chmod 755 gives executable access and chmod 644 is common for files. A professional user asks deeper questions.

Who owns the file?

Which group owns it?

Which user runs the process that needs access?

Does every parent directory allow traversal?

Is the execute bit missing on a directory?

Is the file controlled by ACL rules?

Is a special permission bit active?

Is the default creation mask causing new files to have unexpected permissions?

Is a service writing files as a different user than expected?

Linux permission problems often look simple from the outside, but the cause may be one level deeper than the file itself.

Review of standard permission logic

Run:

ls -l file.txt

Example output:

-rw-r----- 1 pat www-data 1200 May 14 10:20 file.txt

This line tells you the file type, permissions, owner, group, size, time and name.

The permission part is:

-rw-r-----

Break it down:

The owner is:

pat

The group is:

www-data

This means user pat can read and write. Members of group www-data can read. Everyone else has no access.

For directories, execute permission has a special meaning. It means the user can enter or traverse the directory.

Example:

ls -ld /var/www/site

Output:

drwxr-x--- 5 deploy www-data 4096 May 14 10:20 /var/www/site

This means:

If a web server runs as www-data, it can read files inside this directory only if the files and all parent directories allow it.

This is why the command below is extremely useful:

namei -l /var/www/site/index.html

It shows permissions for each path component, not only the final file.

umask controls default permissions for new files

When a user or process creates a new file, Linux does not usually create it with full open permissions. The final permissions are influenced by a value called umask.

Show current umask:

umask

Example output:

0022

The umask removes permissions from the default creation mode.

Typical defaults are:

If the umask is 022, then:

That is why new files are often created as 644 and new directories as 755.

If the umask is 002, then:

This is common in collaborative group environments where group members should be able to write.

Set umask temporarily:

umask 002

Create a file and directory:

touch test-file
mkdir test-directory
ls -l
ls -ld test-directory

The permissions will reflect the active umask.

Why umask matters:

You can set umask inside a script.

#!/bin/bash

umask 002

mkdir -p /var/www/site/cache
touch /var/www/site/cache/example.cache

This ensures new files created by the script follow the intended permission pattern.

setgid directories keep group ownership consistent

A common problem in shared directories is inconsistent group ownership.

Suppose a project directory is owned by group www-data.

ls -ld /var/www/site

Output:

drwxrwxr-x 5 deploy www-data 4096 May 14 10:20 /var/www/site

If user deploy creates a new file, the file may be owned by the user’s primary group, not necessarily www-data.

The setgid bit on a directory helps solve this. When setgid is active on a directory, new files and subdirectories created inside it inherit the directory’s group.

Set setgid on a directory:

sudo chmod g+s /var/www/site

Check:

ls -ld /var/www/site

Output may show:

drwxrwsr-x 5 deploy www-data 4096 May 14 10:20 /var/www/site

The s in the group execute position indicates setgid.

Apply to directories recursively:

sudo find /var/www/site -type d -exec chmod g+s {} \;

A practical collaborative web directory setup may look like this:

sudo chown -R deploy:www-data /var/www/site
sudo find /var/www/site -type d -exec chmod 2775 {} \;
sudo find /var/www/site -type f -exec chmod 664 {} \;

The leading 2 in 2775 means setgid.

Use this carefully. It is useful for shared project directories, but it should not be applied blindly across the system.

Sticky bit protects shared directories

The sticky bit is commonly used on shared writable directories such as /tmp.

Check /tmp:

ls -ld /tmp

Typical output:

drwxrwxrwt 10 root root 4096 May 14 10:20 /tmp

The t at the end means sticky bit.

A directory with sticky bit allows multiple users to create files, but users cannot delete files owned by other users unless they have appropriate privileges.

This is important for shared temporary directories.

Set sticky bit:

sudo chmod +t shared-directory

Numeric form:

sudo chmod 1777 shared-directory

A permission of 1777 means:

This is appropriate for directories like /tmp, not for ordinary web application directories.

Do not use 1777 as a lazy fix for permission problems. It is for specific shared temporary use cases.

setuid is powerful and risky

The setuid bit allows an executable file to run with the permissions of the file owner, not the user who launched it.

A classic example is passwd.

ls -l /usr/bin/passwd

Output may look like:

-rwsr-xr-x 1 root root 68208 May 14 10:20 /usr/bin/passwd

The s in the owner execute position means setuid.

Why does passwd need this? A normal user must be able to change their password, but password data is stored in protected system files. The command needs controlled elevated privileges.

Set setuid:

sudo chmod u+s executable-file

Numeric form:

sudo chmod 4755 executable-file

The leading 4 means setuid.

Setuid is dangerous when applied incorrectly. A vulnerable setuid root program can become a serious security problem.

Find setuid files:

sudo find / -perm -4000 -type f -exec ls -lh {} \; 2> /dev/null

This command searches for files with setuid bit set.

You do not need to modify setuid files in normal administration unless you know exactly why.

ACLs provide permissions beyond owner group others

Standard permissions allow one owner, one group and others. Sometimes this is not flexible enough. Linux ACLs, access control lists, allow more detailed permission rules.

Check ACLs:

getfacl file.txt

Set ACL for a user:

setfacl -m u:alice:rw file.txt

This gives user alice read and write access to file.txt.

Set ACL for a group:

setfacl -m g:editors:rw file.txt

Remove ACL for a user:

setfacl -x u:alice file.txt

Set default ACL on a directory:

setfacl -m d:g:editors:rwx shared-directory

Default ACLs apply to newly created files and directories inside that directory.

Show ACLs:

getfacl shared-directory

If ls -l shows a plus sign after permissions, ACLs exist.

Example:

-rw-r-----+ 1 pat www-data 1200 May 14 10:20 file.txt

The + means extended ACLs are present.

ACLs are powerful, but they can also make permission troubleshooting more complex. If normal chmod and chown do not explain access behavior, check ACLs.

getfacl /path/to/file

sudo is controlled by policy

The sudo command does not magically give everyone root access. It checks policy. That policy is usually configured through the sudoers system.

The safest way to edit sudoers is:

sudo visudo

Do not edit the sudoers file with a normal editor unless you know exactly what you are doing. visudo checks syntax before saving, reducing the risk of locking out administrative access.

A common sudoers rule looks like:

%sudo   ALL=(ALL:ALL) ALL

This means members of group sudo can run commands as any user and group on any host, after authentication.

Check your groups:

id

If your user is in the sudo group, sudo access may be granted depending on configuration.

Add user to sudo group:

sudo usermod -aG sudo username

The user usually needs to log out and back in for group membership to apply.

Test sudo access:

sudo -v

Run a command:

sudo whoami

Expected output:

root

List allowed sudo commands:

sudo -l

This shows what the current user is allowed to run through sudo.

The sudoers.d directory

Many systems support additional sudo rules under:

/etc/sudoers.d/

List files:

sudo ls -lah /etc/sudoers.d/

Create a controlled rule with visudo:

sudo visudo -f /etc/sudoers.d/deploy

Example rule:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx

This allows user deploy to reload Nginx without a password, but only that command.

This is much safer than giving full passwordless root access.

Bad rule:

deploy ALL=(ALL) NOPASSWD: ALL

This allows everything without a password. It may be too broad for many situations.

Better rules are specific.

Least privilege applies to sudo too.

Understanding file ownership after extraction

When extracting archives, ownership can matter.

Extract as normal user:

tar -xzf archive.tar.gz

Files may be owned by the extracting user depending on archive and options.

Extract as root:

sudo tar -xzf archive.tar.gz -C /

This may preserve original numeric ownerships, which can be desired for system restores but dangerous if the archive is untrusted.

Inspect archive first:

tar -tzvf archive.tar.gz | head -30

The -v option shows details such as permissions and ownership.

Safer extraction into test directory:

mkdir -p /tmp/extract-test
tar -xzf archive.tar.gz -C /tmp/extract-test
ls -lah /tmp/extract-test

Never extract an unknown archive directly into /, /etc, /usr or a production directory without inspection.

Package management and software installation

Package management is the safest normal way to install, update, remove and investigate software on Debian-based Linux systems.

Package management is the safest way to install software on Linux

Installing software on Linux should usually be done through a package manager. A package manager is not only a download tool. It is a controlled system for finding software, installing it, updating it, verifying dependencies, removing it and keeping the operating system consistent.

On Debian-based systems such as Debian, Ubuntu, Linux Mint, Raspberry Pi OS and many server distributions derived from Debian, the most common package tool is apt.

When you install a program through apt, Linux does more than place one executable file somewhere on the disk. It checks repositories, reads package metadata, resolves dependencies, downloads the correct package versions, installs required libraries, registers the package in the local package database and often configures service files, documentation and default settings.

This matters because Linux software rarely exists as one isolated file. A web server, programming language, database system or desktop application may depend on many libraries and supporting packages.

For example, when you install a package such as apache2, the system may also install required dependencies. When you remove it later, the package manager knows what was installed and can manage it cleanly.

A beginner may think installing software means downloading a random file from a website. On Linux, that should not be the first habit. The first habit should be: search the package manager.

apt search package-name

Then install using:

sudo apt install package-name

This approach is safer, easier to update and easier to undo.

Understanding repositories

A repository is a software source. It contains packages prepared for your distribution and version. Your system does not automatically know every software package in the world. It knows the repositories configured on that machine.

Repository configuration is commonly stored in files under:

/etc/apt/sources.list

and:

/etc/apt/sources.list.d/

You do not need to edit these files for normal package installation, but it is useful to know they exist.

When you run:

sudo apt update

your system contacts configured repositories and downloads fresh package lists. It does not upgrade your software yet. It only refreshes the local knowledge of what is available.

When you run:

sudo apt upgrade

your system installs newer versions of packages that are already installed, if upgrades are available.

This distinction is essential.

A correct update workflow usually looks like this:

sudo apt update
sudo apt upgrade

This means: first refresh the list of available software versions, then upgrade installed packages.