Skip to content
Back to blog
LinuxDevOpsShellCommand LineServers

Linux Essentials for Developers: Shell, Filesystem & Permissions

July 4, 202612 min read

Most production servers, Docker hosts, and CI runners run Linux. You do not need to become a sysadmin, but every backend and full-stack developer should be comfortable on the command line — navigating files, reading logs, checking processes, and fixing permissions when a deploy fails.

This guide covers the Linux skills that come up daily in real work: essential shell commands, how the filesystem is organized, how permissions work, and how to inspect running services. Practice these on a local VM, WSL, or a free cloud instance until they feel automatic.

Shell\nCommandsFilesystem\n& PathsPermissions\nchmod/chownProcesses\n& Services
Linux skills every developer needs

Command Line Fundamentals

The shell is your interface to the operating system. Bash (or Zsh on macOS) reads commands, runs programs, and chains output through pipes. Start with navigation: `pwd` shows where you are, `cd` changes directory, and `ls -la` lists files with permissions and hidden dotfiles. Use tab completion — type the first few characters and press Tab to finish filenames and commands.

Searching and filtering is where the shell saves hours. `grep -r "error" /var/log` finds lines across files; `find . -name "*.ts"` locates files by pattern; `head` and `tail` show the start or end of logs (`tail -f` follows live output). Redirect output with `>` (overwrite) and `>>` (append), and pipe between commands: `cat access.log | grep 500 | wc -l` counts server errors.

ls -lagrep .logwc -lresult: 42Pipe (|) connects stdout of one command to stdin of the next
Shell: command → output → pipe to next command

Quick reference

  • `ls -la` — list all files with permissions, owner, size, and modified date.
  • `cd -` — jump back to the previous directory (like a browser back button).
  • `grep -i pattern file` — case-insensitive search; add `-r` to search recursively.
  • `man command` — built-in manual; use `--help` for quick usage summaries.
  • History: `!!` repeats last command; `Ctrl+R` searches command history interactively.
  • Aliases in `~/.bashrc`: `alias ll='ls -la'` saves typing on every session.

Remember this

Master navigation, search, and pipes first — they cover 80% of daily terminal work.

Filesystem Layout & File Operations

Linux organizes everything under a single root `/`. User home directories live in `/home/username`. System configuration sits in `/etc`. Logs go to `/var/log`. Installed software and libraries are under `/usr`. Temporary files use `/tmp`. Knowing this layout means you know where to look when something breaks — nginx config in `/etc/nginx`, app logs in `/var/log`, binaries in `/usr/bin`.

Create and move files with `mkdir -p path/to/dir` (creates parent folders), `cp -r src dest` for directories, `mv old new` to rename or move, and `rm -rf` to delete recursively (use carefully). View file contents with `cat`, paginated with `less`, or the first/last lines with `head`/`tail`. For large files, `less` is safer than `cat` — it does not flood your terminal.

/ (root)/home\nusers/etc\nconfig/var\nlogs/usr\nbinaries/tmp\ntemp
Standard Linux directory layout

Quick reference

  • `/` — root; `/home` — user files; `/etc` — config; `/var` — logs and data; `/tmp` — temp files.
  • `mkdir -p a/b/c` — create nested directories in one command.
  • `du -sh *` — disk usage per item in the current folder (find what is eating space).
  • `df -h` — free disk space on mounted filesystems (critical before deploys).
  • Dotfiles (`.bashrc`, `.ssh/`) store shell and SSH configuration in your home directory.
  • Use `touch file` to create an empty file or update its modified timestamp.

Remember this

Learn the standard directory layout once — you will always know where configs and logs live.

Users, Groups & Permissions

Every file has an owner, a group, and permission bits for user/group/others: read (r), write (w), execute (x). Run `ls -l` and you see something like `-rw-r--r-- 1 deploy deploy 4096 Jul 4 app.conf` — the owner can read and write; group and others can only read. Directories need execute permission to enter them, even if you can read the listing.

Change permissions with `chmod`: `chmod 644 file` sets rw-r--r--, or use symbolic form `chmod u+x script.sh` to add execute for the owner. Change ownership with `chown user:group file` (usually requires sudo). When a web server cannot read a config or a deploy script fails with "Permission denied", check owner and mode first before assuming a code bug.

- rw- r-- r-- deploy deploy app.confOwner (u)\nrw-Group (g)\nr--Others (o)\nr--chmod 644 app.conf · chown user:group file
Permission bits: owner | group | others

Quick reference

  • Numeric modes: 4=read, 2=write, 1=execute — add them (644 = rw-r--r--, 755 = rwxr-xr-x).
  • `sudo` runs a command as root — use sparingly and only when necessary.
  • `whoami` and `id` show your current user and group memberships.
  • Scripts need execute bit (`chmod +x deploy.sh`) before you can run `./deploy.sh`.
  • Never `chmod 777` in production — it exposes files to every user on the system.
  • SSH keys in `~/.ssh/` should be `600` for private keys and `644` for public keys.

Remember this

Permission errors are common in deploys — read `ls -l`, fix owner with chown, mode with chmod.

Processes, Services & Logs

Everything running on Linux is a process. `ps aux` lists all processes; `top` or `htop` shows live CPU and memory usage. Find a process by name with `pgrep -a nginx` or kill one with `kill PID` (SIGTERM) or `kill -9 PID` (force — last resort). When an app hangs, check if the process exists and whether it is consuming CPU or stuck waiting on I/O.

Services on modern distros are managed by systemd. `systemctl status nginx` shows whether a service is running; `journalctl -u nginx -f` tails its logs. Application logs often live in `/var/log/` — read them with `tail -f /var/log/syslog` during debugging. Remote servers are accessed via SSH: `ssh user@host` using key-based auth (no password in scripts).

ps aux / htop\nIs it running?systemctl status\nService statejournalctl / tail\nRead logs
Debug workflow: process → service → logs

Quick reference

  • `ps aux | grep node` — find Node processes; note the PID in the second column.
  • `systemctl start|stop|restart|enable service` — control and auto-start on boot.
  • `journalctl -xe` — recent system log entries with explanations (great after failures).
  • `lsof -i :3000` — see which process is listening on port 3000 (port conflicts).
  • SSH config in `~/.ssh/config` can store host aliases and key paths.
  • `curl localhost:8080/health` — quick check that a service responds on the server.

Remember this

When something is down: check the process, check the service status, then read the logs.

Key takeaway

Share:

You do not need to memorize every Linux command — you need a reliable workflow: navigate the filesystem, read permissions, inspect processes, and tail logs. Install WSL on Windows or spin up a small Ubuntu VM, practice these commands daily for two weeks, and they will stick. Pair this foundation with Docker and CI/CD articles on CoreConcept, and you will be comfortable on any production server you deploy to.

Related Articles

Manual deployments are one of the highest-risk activities in software engineering. A developer SSHes into a production s

Read

When a production system breaks at 3am, you need to answer three questions fast: what happened, how bad is it, and where

Read
DockerKubernetes

Docker and Kubernetes are often mentioned together, but they solve different problems. Docker packages your application

Read

Explore this topic

Keep learning

Follow a structured path or browse all courses to go deeper.