← All articles
LinuxWindowsCareer

How to Learn Linux as a Windows Admin

4 March 2026 · 10 min

You've spent years in Active Directory, Group Policy, and the MMC snap-in ecosystem. You know your way around Event Viewer, you can write a decent PowerShell script, and you've memorised more Windows Server hotfixes than you'd care to admit. Now your team is running Kubernetes on Ubuntu, your new role requires SSH instead of RDP, and suddenly you're staring at a bash prompt with no Start menu in sight.

This isn't about starting from zero. You already think like a systems engineer — you understand services, permissions, logging, and networking. What you need is a translation layer: a way to map what you already know onto how Linux works. That's exactly what this guide provides.

The Core Mindset Shift

The single biggest trap Windows admins fall into on Linux is looking for the GUI equivalent of everything. There isn't one — and that's a feature, not a bug. Linux systems in production are almost always managed entirely via the command line, and the tooling is designed around that assumption.

A second trap is assuming that because bash looks a bit like PowerShell, they work the same way. They don't. PowerShell passes objects down the pipeline. Bash passes text. This distinction shapes everything: how you filter output, how you parse logs, how you chain commands together. Once it clicks, it's liberating. Until it clicks, it's maddening.

Think of your Windows knowledge as a foundation, not baggage. Almost every concept maps across — it just maps somewhere unexpected.

Windows → Linux Concept Map

WindowsLinux Equivalent
Services (SCM)systemd units (systemctl)
Event Viewerjournalctl / /var/log/
RegistryPlain-text config files (usually in /etc/)
Task Managertop, htop, ps
PowerShell pipeline (objects)Bash pipeline (text streams)
NTFS ACLs / icaclschmod, chown, umask
Active Directory users/groupsLocal users, /etc/passwd, /etc/group, sudo
Group PolicyConfig files, PAM, /etc/sudoers
ipconfigip addr, ip route
netstatss, netstat (same name, slightly different flags)
Windows Firewalliptables, nftables, ufw
MSI / Windows Updateapt, dnf, yum, snap
%APPDATA%~/.config/, ~/.local/
C:\Program Files/usr/bin/, /usr/local/bin/, /opt/
Scheduled Taskscron, systemd timers

Keep this table handy during your first month. You'll refer to it constantly.

Navigating the Filesystem

Forget drive letters. Linux has one root: /. Everything hangs off it — disks, network shares, virtual filesystems, the lot. Where you'd look in C:\Windows\System32, you'll now look in /usr/bin or /usr/sbin. Where you'd look in C:\ProgramData, you'll look in /etc or /var.

The most important directories to learn first:

  • /etc — system-wide configuration files (your new Registry)
  • /var/log — logs (your new Event Viewer)
  • /home/<user> — user home directories (like C:\Users\)
  • /tmp — temporary files, cleared on reboot
  • /proc and /sys — virtual filesystems exposing kernel internals (read-only, fascinating)
# Orient yourself quickly on any new Linux box
uname -a                  # kernel version and architecture
lsb_release -a           # distro name and version
df -h                    # disk usage across all mounts
free -h                  # RAM and swap
ip addr show             # network interfaces and IPs
systemctl list-units --type=service --state=running

That last command is your new "Services" MMC snap-in.

Permissions: rwx vs NTFS ACLs

Windows NTFS permissions are powerful but verbose — a single file can inherit a chain of ACEs from multiple groups with Allow/Deny entries at each level. Linux permissions are simpler by design: every file has an owner (user), a group, and a set of read/write/execute bits for three audiences — the owner, the group, and everyone else.

The output of ls -l will look cryptic at first:

$ ls -l /etc/nginx/nginx.conf
-rw-r--r-- 1 root root 2.8K Jun 10 09:15 /etc/nginx/nginx.conf

Break that permission string down: -rw-r--r--

  • - — regular file (directories show d, symlinks show l)
  • rw- — owner (root) can read and write
  • r-- — group (root) can only read
  • r-- — everyone else can only read

chmod changes permissions, chown changes ownership. The chmod calculator on ShellQuest lets you build permission strings visually until the octal notation (755, 644, 600) becomes second nature. Full detail on the permission model is covered in Linux file permissions.

Logs: journalctl is Your New Event Viewer

If you've spent time in Event Viewer filtering by Event ID, Source, and time range, journalctl will feel both familiar and more powerful once you learn the flags:

# Show logs for a specific service, newest first
journalctl -u nginx --reverse

# Show logs since a specific time
journalctl --since "2026-06-14 08:00" --until "2026-06-14 09:00"

# Follow live output (like tail -f)
journalctl -u postgresql -f

# Show only errors and above
journalctl -p err -b

# Logs from the last boot
journalctl -b 0

For services that log directly to files rather than the journal (some still do), check /var/log/nginx/error.log, syslog, auth.log, and so on. The pattern tail -f /var/log/syslog is the Unix equivalent of watching an Event Viewer live feed.

Users, Groups, and sudo

Active Directory is a full identity platform — LDAP, Kerberos, Group Policy, the works. On a standalone Linux server, identity is much simpler: users live in /etc/passwd, their group memberships in /etc/group, and their hashed passwords in /etc/shadow.

The critical concept for Windows admins is sudo. There is no "Run as Administrator" — you either are root (uid 0) or you invoke sudo for elevated commands. Who can use sudo, and for what, is controlled by /etc/sudoers (edit it safely with visudo, never directly). On Ubuntu and Debian systems, adding a user to the sudo group grants full sudo access — the equivalent of putting someone in the local Administrators group.

Your First-Week Learning Plan

Day 1 — Orient. Spin up an Ubuntu 24.04 LTS VM (free on any cloud, or use VirtualBox locally). Log in, run the orientation commands above, explore the filesystem with ls, cd, cat, and less. Don't install anything yet.

Day 2 — Files and permissions. Create, move, copy, and delete files. Use chmod and chown. Try to break something safely and fix it. Read the Linux file permissions guide.

Day 3 — Processes and services. Use ps aux, top, and kill. Start and stop a service with systemctl. Check its logs with journalctl.

Day 4 — Networking. Use ip, ss, curl, and dig. Compare the output of ss -tulnp to what you'd expect from netstat -ano on Windows.

Day 5 — Text processing. This is where Linux diverges most sharply from PowerShell. Spend a morning on grep, awk, sed, sort, uniq, and wc. Pipe them together. Parse a log file. Resist the urge to write a Python script for everything — the shell tools are faster than you think.

Day 6–7 — A real task. Install nginx, configure a virtual host, set up a systemd service to run a simple script on a schedule, and review the logs. Follow the Linux track on ShellQuest for structured exercises that build on each other.

Common Traps

Case sensitivity. File.txt and file.txt are different files. This trips up Windows admins constantly.

Line endings. Windows uses CRLF, Linux uses LF. Scripts copied from Windows boxes can fail mysteriously. Use dos2unix to fix them.

No mandatory file extensions. .exe, .bat, .ps1 — none of that. A file is executable if the execute bit is set, regardless of its name. chmod +x myscript and then ./myscript.

sudo vs su. su - switches you to the root user entirely (requires root's password). sudo <command> runs a single command as root (requires your password, if you're in the sudoers file). Prefer sudo on modern systems.

Editing files as root. sudo nano /etc/nginx/nginx.conf — don't forget sudo, or you'll edit the file, try to save, and get a permission denied error. Yes, this happens to everyone.

Keep the Momentum

The biggest mistake is trying to learn Linux abstractly, away from real work. The fastest path is deliberate daily practice on problems that matter to your actual job. Every day you spend on the command line compounds — muscle memory builds, patterns click into place, and the prompt stops feeling hostile.

Try today's ShellQuest daily challenge — bite-sized, scenario-driven, and designed for working engineers who have twenty minutes, not twenty hours. When you're ready to go deeper, join the waitlist for the ShellQuest app and get early access to the full Linux track, interactive labs, and structured skill-building that takes you from Windows admin to confident Linux engineer.

Liked this? ShellQuest turns these mental models into puzzles and labs you can actually practise.

Join the waitlist