Linux Essentials for Developers: Shell, Filesystem & Permissions
Most production servers, container hosts, and CI runners use Linux. A developer does not need full system-administration depth, but should be able to navigate files, read permissions, inspect processes, and gather evidence when a deployment fails. The same host skills support Docker volume troubleshooting when files and permissions cross a container boundary.
Learn those skills through one concrete incident: orders-api returns no response on port 8080 after a deploy. The commands below move from filesystem and identity checks to service status, logs, listening ports, and a verified restart. If the failed process is an edge proxy, continue with the NGINX gateway guide.
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: grep ' 500 ' access.log | wc -l counts server errors.
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-rto search recursively.man command— built-in manual; use--helpfor quick usage summaries.- History:
!!repeats last command;Ctrl+Rsearches 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.
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 fileto 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.
Quick reference
- Numeric modes: 4=read, 2=write, 1=execute — add them (644 = rw-r--r--, 755 = rwxr-xr-x).
sudoruns a command as root — use sparingly and only when necessary.whoamiandidshow your current user and group memberships.- Scripts need execute bit (
chmod +x deploy.sh) before you can run./deploy.sh. - Never
chmod 777in production — it exposes files to every user on the system. - SSH keys in
~/.ssh/should be600for private keys and644for 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).
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/configcan 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
A reliable Linux workflow is evidence-first: identify the current user and path, inspect ownership and modes, confirm the process and listening socket, read the service logs, then change one thing and verify the health endpoint.
Practice (25 min): Use a disposable systemd service or an existing local service with its real unit name and port; first capture a successful health request and listening socket. Intentionally stop the service so curl fails, then inspect status, logs, process, and port before restarting it. Recover with the normal service command rather than kill -9 or chmod 777. Pass when you retain the failed curl, decisive evidence, restart result, and successful curl, and can explain which boundary actually failed.
Related Articles
Explore this topic