100 Linux Scenario-Based Questions & Answers
100 Linux Scenario-Based Questions & Answers: Master Linux with these 100 real-world, scenario-based questions and answers. Perfect for interviews, sysadmin prep, DevOps, and practical Linux troubleshooting.
I. File System & Permissions (Core Concepts)
Q1. User can see (ls) a file but cannot edit it.
Scenario: User lists a file but gets Permission denied when opening it with an editor like vim or nano.
Root Cause: They have read permission (r) but not write permission (w) on the file. Editing requires write access.
Solution:
Check ownership and permissions: ls -l /path/to/file
Fix ownership (if needed): sudo chown username:groupname /path/to/file
Or add write permission: sudo chmod u+w /path/to/file
Tip: Always use group permissions instead of giving everyone (others) write access for corporate systems.
Q2. Cannot run a newly created shell script — “Permission denied”.
Scenario: Created a script but getting Permission denied even though it exists.
Root Cause: Script is missing executable (x) permission.
Solution:
Make it executable: chmod +x script.sh
Then run: ./script.sh
Tip: Always verify both the shebang (#!/bin/bash) and permissions when troubleshooting scripts.
Q3. User can’t access their own home directory.
Scenario: User gets “Permission denied” when trying to cd into their home.
Root Cause: Wrong ownership or permission settings on the home directory.
Solution:
Fix ownership: sudo chown username:username /home/username
Fix permissions: chmod 700 /home/username
Tip: Corporate servers often set /home/username with 700 or 750 permissions for security.
Q4. Created a new directory but can’t cd into it — “Permission denied”.
Scenario: After creating a directory, the user cannot access it via cd, even though they own it.
Root Cause: Directory is missing execute (x) permission, which is required to enter (cd) a directory.
Solution:
Check permissions: ls -ld /path/to/dir
Add execute permission: chmod +x /path/to/dir
Tip: Directories need execute permission to enter, and read permission to list their contents.
Q5. “Permission denied” when creating file under /tmp/.
Scenario: Even in /tmp/, user cannot create or write files and gets permission denied.
Root Cause: Permissions on /tmp were accidentally changed. /tmp should have 1777 permissions (world-writable with sticky bit).
Solution:
Check permissions: ls -ld /tmp
Restore correct permissions: sudo chmod 1777 /tmp
Tip: /tmp must always have 1777 permissions; without it, apps and users can face weird errors.
Q6. Mistakenly set wrong permission on /etc/passwd, users can’t login.
Scenario: Users are unable to login after wrong permissions were set on /etc/passwd.
Root Cause: Critical system files like /etc/passwd must have proper permissions.
Solution:
Boot into recovery mode.
Correct permissions: chmod 644 /etc/passwd
Tip: Use ls -l carefully when changing permissions on system files; mistakes can break authentication.
Q7. User created directory but team members can’t write into it.
Scenario: One user creates a project folder, but others cannot create files inside it.
Root Cause: Group write permissions missing.
Solution:
Set correct group ownership: sudo chown :projectgroup /path/to/projectdir
Add group write permission: chmod g+w /path/to/projectdir
Tip: Use setgid bit (chmod g+s) on shared directories to automatically inherit group ownership for new files.
Q8. Group permissions are not working as expected.
Scenario: A file is owned by user:projectgroup with permissions rw-rw-r–. Another user belonging to projectgroup tries to edit the file but gets “Permission denied”.
Root Cause: The user might not actually be a member of projectgroup in their current session (group memberships are typically applied at login), the file permissions don’t actually grant group write (w), or filesystem mount options might override permissions (e.g., noexec, ro).
Solution:
Verify the user’s current group memberships: id -Gn <username>.
If the group is missing, the user needs to log out and log back in after being added to the group (sudo usermod -aG projectgroup <username>). A quick check can be done using newgrp projectgroup which starts a subshell with that group active.
Verify file permissions: ls -l /path/to/file. Ensure the middle triplet has w. If not, fix it: chmod g+w /path/to/file.
Check filesystem mount options: mount | grep $(df /path/to/file | awk ‘NR==2 {print $1}’). Look for restrictive options like ro.
Tip: Remember that group membership changes require a new login session to take effect for the user’s primary processes.
Q9. Set default permissions for newly created files within a shared directory.
Scenario: In a directory shared by a group (/data/project), newly created files need to automatically have group write permissions (rw-rw-r–) instead of the default (rw-r–r–).
Root Cause: Default file creation permissions are controlled by umask, but need group inheritance for shared environments.
Solution:
Set the setgid (Set Group ID) bit on the shared directory: sudo chmod g+s /data/project.
This ensures new files/directories created within /data/project inherit the group ownership from the directory itself, rather than the user’s primary group.
Adjust the umask for users working in that directory (can be set in ~/.bashrc or system-wide profiles), or rely on applications respecting the setgid behavior. A umask of 002 allows group write by default (666 – 002 = 664 or rw-rw-r–).
Ensure the directory itself has group write permissions: sudo chmod g+w /data/project.
Tip: Combining setgid (chmod g+s) on the directory with appropriate group ownership (chown :projectgroup /data/project) and group write permission (chmod g+w /data/project) is the standard way to manage collaborative directories where group members need to modify each other’s files.
Q10. A symbolic link shows “No such file” after reboot.
Scenario: A previously working symlink is now broken, showing “No such file or directory”.
Root Cause: The symlink points to a file that was either on a temporary filesystem (e.g., /tmp) or deleted.
Solution:
Check where symlink points: ls -l /path/to/symlink
Correct the target if needed: ln -sf /correct/target/path /path/to/symlink
Tip: Prefer absolute paths when creating symlinks for important files.
Q11. Accidentally moved files to the wrong location.
Scenario: mv * /wrong/path/ by mistake; files need to be moved back.
Root Cause: Wrong destination path supplied in mv command.
Solution: Move back: find /wrong/path/ -type f -exec mv {} /correct/path/ \; Or manually move using mv.
Tip: Use mv -i (interactive) to avoid accidental overwrites.
Q12. cp -r fails midway when copying a large directory.
Scenario: Copying a huge directory with cp -r stops with errors like “No space left on device” or permission errors.
Root Cause:
Disk may be full.
Permission issues on some files.
Filesystem limits like inode exhaustion.
Solution:
Check disk space: df -h
Check inode usage: df -i
If permission errors: sudo cp -rp source/ destination/ (-p preserves ownerships.)
Tip: When copying critical data, use rsync -a instead of cp -r for better control and resume support.
Q13. “Argument list too long” when deleting thousands of files.
Scenario: Running rm *.log on a folder with 100,000+ files throws “Argument list too long” error.
Root Cause: Shell has a maximum command-line argument length (around 128KB).
Solution: Use find instead of wildcards: find . -name “*.log” -delete
Tip: For mass file operations, find is always more reliable and scalable.
Q14. Accidentally deleted a config file like /etc/ssh/sshd_config.
Scenario: Important system config file is accidentally deleted, system services depending on it might break after restart.
Root Cause: When you delete a file, only its metadata link is removed. If the file is open by a running service, recovery is possible.
Solution:
Find if any process is still using the deleted file: lsof | grep deleted
Recover the file: cp /proc/PID/fd/FD /path/to/newfile
If no running process:
Need to restore from backup
If no backup, use file system recovery tools (like extundelete).
Tip: Always configure automatic daily backups of /etc to avoid system outage due to config loss.
Q15. chown or chmod fails with “Operation not permitted”.
Scenario: Even when running as root, attempting to change ownership (chown) or permissions (chmod) on certain files fails.
Root Cause: The file has the immutable attribute set, or it resides on a filesystem mounted read-only or a specific type (like NFS with root squashing) that prevents the operation.
Solution:
Check file attributes: lsattr /path/to/file. If the i (immutable) attribute is present, remove it: sudo chattr -i /path/to/file.
Check filesystem mount status: mount | grep $(df /path/to/file | awk ‘NR==2 {print $1}’). Ensure it’s not mounted ro (read-only). Remount read-write if needed: sudo mount -o remount,rw /mount/point.
If on NFS, check the server’s export options (/etc/exports). root_squash (default) maps root user to nobody, preventing root actions. Use no_root_squash cautiously if root needs to manage files directly on the client.
Tip: The chattr command can set various extended file attributes. The immutable (i) and append-only (a) attributes are often used to protect critical files from accidental modification or deletion, even by root.
II. Disk Usage & Management
Q16. Disk is 100% full, can’t create or write files.
Scenario: App logs stop, can’t save files, or services crash. df -h shows 100% usage.
Root Cause: A large log, backup file, or temporary file has filled the disk.
Solution:
Find the largest files: du -sh /* | sort -h or use ncdu /
Remove or compress large files: gzip huge-log.log
Tip: Configure log rotation (logrotate) to prevent runaway log files.
Q17. Finding out which file is filling up the disk.
Scenario: Disk is almost full but unsure which files/folders are consuming space.
Root Cause: Hidden huge logs, database dumps, or backup folders.
Solution: Find largest directories/files: du -ahx / | sort -rh | head -20 or ncdu / (ncdu gives an interactive disk usage view.)
Tip: Schedule weekly disk audits in production servers to prevent sudden disk full incidents.
Q18. Filesystem showing used space but no visible files.
Scenario: df -h shows disk full but ls -lh shows no big files.
Root Cause: Deleted files are still held by running processes and occupying space.
Solution:
Find deleted files: lsof | grep deleted
Kill the processes using those files: kill PID
Disk space will be freed.
Tip: On production, avoid killing critical daemons; restart them gracefully if possible.
Q19. Disk shows 0% free in df -h, but du -sh shows little usage.
Scenario: Disk shows full, but there are no large files in sight.
Root Cause: Files were deleted but are still held open by a running process.
Solution:
Find such processes: lsof | grep deleted
Restart the process or: kill -9 <PID>
Tip: Always restart logging services after clearing large logs.
Q20. “No space left on device” but df -h shows free space.
Scenario: df -h shows free space but still can’t write to disk.
Root Cause: Ran out of inodes (metadata structure used for files).
Solution:
Check inode usage: df -i
Clean up folders with many small files (like /var/spool, /tmp): find /var/spool -type f -delete
Tip: Format file systems with more inodes if you expect millions of tiny files (e.g., mail servers).
Q21. “Read-only file system” error when creating or modifying files.
Scenario: Commands like touch, mkdir, or editors fail with Read-only file system error.
Root Cause: The file system was mounted read-only by the OS due to detecting disk or file system corruption to avoid further damage.
Solution:
Confirm filesystem is read-only: mount | grep ro
Check disk errors: dmesg | tail
Reboot into rescue mode and run fsck: sudo fsck /dev/sdX
Allow fsck to fix errors and reboot.
Tip: Monitor disk health regularly using tools like smartctl to detect hardware failure early.
Q22. Filesystem corruption detected on reboot.
Scenario: On boot, system enters emergency mode with fsck errors.
Root Cause: Improper shutdown or hardware issues caused fs corruption.
Solution:
Enter rescue mode.
Run fsck manually: fsck /dev/sdaX
Tip: Always unmount disks cleanly or use journaling filesystems like ext4.
Q23. Tar backup created but getting error while extracting.
Scenario: tar -xvf backup.tar throws errors like “Unexpected EOF” or “corrupt archive”.
Root Cause:
Tarball creation was interrupted.
File got partially copied.
Wrong tar command or compression mismatch.
Solution:
Check if tar is readable: tar -tvf backup.tar
Ignore bad blocks if minor damage: tar –ignore-failed-read -xvf backup.tar
Tip: Always use gzip or bzip2 (tar -czvf) for compression + integrity checks.
III. Performance & Resource Monitoring
Q24. How to check the uptime and load average of the system.
Scenario: Need to quickly assess how long the system has been running since the last boot and what the CPU load has been recently.
Root Cause: Basic system monitoring requirement.
Solution:
Use the uptime command: uptime
Use top or htop: These commands show uptime and load averages in their header section.
Tip: Load average represents the average number of processes running or waiting. Consistently higher load than CPU cores indicates overload.
Q25. System becomes very slow — commands take long to execute.
Scenario: Basic commands like ls, cd, or top take 5–10 seconds to respond.
Root Cause:
System may be out of free RAM and using swap heavily.
High CPU or disk I/O wait also possible.
Solution:
Check memory usage: free -h
Check swap usage: swapon –show
Check CPU and load: top
Check I/O wait: iostat -xz 1
Tip: Set up swapoff -a temporarily to test if swap is the cause; add more RAM or reduce memory-hungry apps.
Q26. top shows one process using 99% CPU.
Scenario: System is slow, one process is hogging the CPU.
Root Cause: An infinite loop, runaway script, or bad query.
Solution:
Identify process: top, ps aux –sort=-%cpu | head
Pause or kill process: kill -STOP PID, kill -9 PID
Tip: Use nice or cpulimit for non-critical CPU-bound processes.
Q27. CPU always runs at 100% on all cores.
Scenario: Even idle system shows high CPU usage on all cores.
Root Cause: Background process like cron, rsync, or malware.
Solution:
Inspect with: top, htop, ps aux –sort=-%cpu
Kill the culprit or analyze further.
Tip: Use auditd or psacct to track rogue activity.
Q28. CPU usage randomly spikes — can’t trace.
Scenario: System becomes slow randomly, CPU usage goes to 100% for a few minutes.
Root Cause:
cron jobs
Background scanning (like updatedb, mlocate, antivirus)
Solution: Check cron: cat /etc/crontab. Check logs: journalctl –since “10 min ago”
Tip: Disable or schedule heavy cron jobs during off-peak hours.
Q29. Load average is high but CPU usage is low.
Scenario: top shows load average > 5, but CPU idle is still high.
Root Cause: Load average includes processes waiting for disk or I/O, not just CPU.
Solution:
Check I/O wait: iostat -xz 1
Check blocked processes: vmstat 1
Tip: Use SSDs and proper disk schedulers for high-I/O workloads.
Q30. Disk I/O spikes suddenly — application slows down.
Scenario: Random performance lag. iostat shows high %util and await.
Root Cause: Too many read/write operations from one or more processes.
Solution:
Use iotop to identify culprit: sudo iotop
Pause or throttle process: ionice -c2 -n7 -p <PID>
Tip: Use dedicated disk partitions for logs or data-heavy apps.
Q31. Disk write speed is very low.
Scenario: Copying large files is taking unusually long time.
Root Cause:
Disk I/O contention.
Wrong disk scheduler.
Fragmentation.
Solution:
Benchmark: dd if=/dev/zero of=testfile bs=1G count=1 oflag=dsync
Check scheduler: cat /sys/block/sdX/queue/scheduler
Tip: Use deadline or noop scheduler for SSDs.
Q32. Application performance drops when copying files.
Scenario: App slows down whenever a large file is copied.
Root Cause: Disk I/O contention; both app and copy operation use same disk.
Solution:
Use ionice for background copy: ionice -c3 cp file /target/
Tip: Use dedicated storage for app vs backups/logs.
Q33. RAM usage shown as full, but system is fast.
Scenario: free -h shows most of the memory used, but no lag.
Root Cause: Linux caches file system I/O in memory.
Solution: Check actual usage: free -h. Look at “available”, not “used”.
Tip: Don’t panic if RAM is full — Linux intelligently caches it.
Q34. “Cannot allocate memory” error when starting services.
Scenario: A service fails to start due to memory allocation errors.
Root Cause: Out of RAM or ulimit limits exceeded.
Solution:
Check available RAM: free -m
Check and increase memory limits: ulimit -a, ulimit -v unlimited
Tip: Set permanent limits in /etc/security/limits.conf for critical services.
Q35. RAM is free, but app complains “cannot allocate memory”.
Scenario: App errors out despite RAM being available.
Root Cause: Per-process memory limit (ulimit) or overcommit policy.
Solution:
Increase limits: ulimit -v unlimited
Tweak overcommit: echo 1 > /proc/sys/vm/overcommit_memory
Tip: Avoid setting overcommit=2 for memory-heavy applications.
Q36. Memory usage slowly increases over time.
Scenario: RAM usage creeps up daily until system swap is used.
Root Cause: Memory leak in a service or cron job.
Solution:
Monitor usage: top, ps aux –sort=-%mem
Restart the leaking service periodically.
Tip: Use monitoring tools like prometheus + grafana to track memory trends.
Q37. Kernel OOM (Out of Memory) kills processes.
Scenario: Processes suddenly die and dmesg shows OOM killer.
Root Cause: System ran out of memory and the kernel killed the biggest consumer.
Solution:
View logs: dmesg | grep -i kill
Tune OOM behavior: echo -17 > /proc/<PID>/oom_score_adj
Tip: Use OOM protection for critical apps like databases using systemd or memory cgroups.
Q38. Swap usage is always high even with free RAM.
Scenario: free -h shows high swap usage even when RAM is available.
Root Cause: Kernel may have aggressively swapped out old memory pages.
Solution:
Reduce swappiness: sysctl vm.swappiness=10
Persist it in /etc/sysctl.conf: vm.swappiness=10
Tip: Swappiness of 10 is ideal for most server workloads.
IV. Networking
Q39. Ping to external websites fails, but internal network is reachable.
Scenario: User can ping local servers but not external IPs like 8.8.8.8.
Root Cause: Missing default gateway, incorrect DNS, or firewall block.
Solution: Check ip route, /etc/resolv.conf, firewall output rules (iptables -L OUTPUT, firewall-cmd –list-all). Add gateway (ip route add default via …), fix DNS, allow outbound traffic.
Tip: Use traceroute 8.8.8.8 to see where connectivity stops.
Q40. DNS resolution fails intermittently.
Scenario: Commands sometimes fail with “Temporary failure in name resolution”.
Root Cause: Unreliable DNS server, packet loss, systemd-resolved issues.
Solution: Check /etc/resolv.conf, test alternate DNS (dig @1.1.1.1 google.com), update DNS settings, check/restart systemd-resolved.
Tip: Configure multiple reliable DNS servers; check packet loss to DNS servers.
Q41. Cannot SSH into a server — “Connection refused”.
Scenario: ssh user@server_ip fails immediately with connection refused.
Root Cause: SSH daemon (sshd) not running on server, or firewall blocking port 22.
Solution (on server): Check sshd status (systemctl status sshd), start if needed (systemctl start sshd), check listening ports (ss -tlpn | grep :22), check firewall input rules (iptables -L INPUT, firewall-cmd –list-ports).
Tip: Ensure sshd is enabled to start on boot: systemctl enable sshd.
Q42. SSH login fails with “Permission denied (publickey,password)”.
Scenario: User tries SSH with seemingly correct credentials, but access is denied.
Root Cause: Incorrect password/key, PasswordAuthentication no, wrong ~/.ssh permissions, user not in AllowUsers, account locked.
Solution (on server): Check sshd logs (journalctl -u sshd, /var/log/auth.log), verify sshd_config settings (PasswordAuthentication, AllowUsers), check ~/.ssh permissions (700 for dir, 600 for authorized_keys), check account status (passwd -S).
Tip: Use ssh -v user@server_ip on the client for verbose debugging info.
Q43. A service (e.g., web server) is not accessible from outside, but works locally.
Scenario: curl http://localhost works, but access via public IP fails.
Root Cause: Firewall blocking port, service bound only to 127.0.0.1, NAT/port forwarding issue.
Solution: Check firewall input rules, check service listening address (ss -tlpn | grep :<port>; should be 0.0.0.0 or public IP), check external firewall/router port forwarding.
Tip: ss -tlpn quickly shows listening ports and interfaces.
Q44. Network interface (e.g., eth0) does not get an IP address via DHCP.
Scenario: Interface shows no inet address after boot/connection.
Root Cause: DHCP client not running, DHCP server unreachable, bad config, physical layer issue (cable/port).
Solution: Check cable/link lights, check interface status (ip link show eth0, ip link set eth0 up), verify NetworkManager/networking config, restart DHCP client (systemctl restart NetworkManager, dhclient -r eth0; dhclient eth0), check logs.
Tip: Try assigning a static IP temporarily to test connectivity.
Q45. Hostname resolution points to the wrong IP address.
Scenario: ping my-internal-server resolves to an old/incorrect IP.
Root Cause: Stale local DNS cache, incorrect /etc/hosts entry, incorrect record on DNS server.
Solution: Check /etc/hosts, clear local cache (systemd-resolve –flush-caches), query DNS server directly (dig @<dns_server_ip> …), check authoritative DNS server.
Tip: Use dig +trace my-internal-server to see the full resolution path.
Q46. High network latency when accessing a specific server.
Scenario: ping specific_server_ip shows high RTT (>100ms).
Root Cause: Network congestion on path, intermediate router issue, target server overload, rate limiting.
Solution: Use traceroute or mtr to identify latency hop, check packet loss (ping -c 50, mtr), check resources on target server.
Tip: mtr provides a dynamic view of latency/loss to each hop.
Q47. Network speed is much slower than expected.
Scenario: File transfers much slower than link speed (e.g., 10MB/s on Gigabit).
Root Cause: Latency/packet loss, duplex mismatch, CPU/disk bottleneck, faulty hardware, QoS.
Solution: Test raw throughput with iperf3, check interface speed/duplex (ethtool eth0), monitor CPU/IO (top, iostat), check latency/loss (ping, mtr), try different cable/port.
Tip: iperf3 isolates network bandwidth testing from disk/app performance.
Q48. Mounted NFS share shows “stale file handle” error.
Scenario: Accessing NFS share gives Stale file handle.
Root Cause: File/folder on server was deleted/modified while client held a reference.
Solution: Force unmount: sudo umount -f /mnt/nfs. Then remount: sudo mount /mnt/nfs.
Tip: Avoid hardcoding paths on NFS; handle stale handles with retry logic if scripting.
Q49. df command hangs or freezes.
Scenario: Running df -h just hangs and never returns.
Root Cause: A mounted NFS or remote filesystem is unavailable.
Solution:
List all mounts: mount | grep nfs
Force unmount: sudo umount -f /mnt/path
Tip: Mount NFS with soft,timeo options to prevent such hangs.
Q50. Unable to mount an NFS share — “mount.nfs: Connection timed out”.
Scenario: sudo mount <nfs_server>:/path /mnt/nfs fails with timeout.
Root Cause: NFS server down/unreachable, firewall blocking NFS ports (111, 2049), NFS service not running, incorrect server export config.
Solution: Check server ping, check ports on server (rpcinfo -p <nfs_server>), check client/server firewalls, check NFS service status on server, check server exports (showmount -e <nfs_server>).
Tip: Use mount -v for verbose output.
Q51. How to check for open network ports and listening services.
Scenario: Need to identify listening ports for security or troubleshooting.
Root Cause: Need to assess network exposure or find process using a port.
Solution: Use ss -tlpn (TCP listen), ss -ulpn (UDP listen), netstat -tlpn (older). Use nmap <server_ip> from external host to verify accessibility.
Tip: Prefer ss over netstat. Use nmap for external view.
V. User & Group Management
Q52. User cannot run commands requiring root privileges, even with sudo.
Scenario: User runs sudo cmd but gets “username is not in the sudoers file”.
Root Cause: User not configured in /etc/sudoers or not in a sudo-enabled group (e.g., wheel, sudo).
Solution (as root/sudoer): Use sudo visudo to edit config. Add user line (username ALL=(ALL:ALL) ALL) or add user to sudo group (sudo usermod -aG wheel username).
Tip: Always use visudo. Group management is usually preferred.
Q53. Newly added user cannot login via SSH.
Scenario: useradd newuser; passwd newuser done, but ssh newuser@server fails.
Root Cause: SSH access restricted (AllowUsers), invalid shell, home dir issues, account locked.
Solution (on server): Check sshd_config (AllowUsers), check user shell (grep newuser /etc/passwd), verify/create home dir and permissions, check account status (passwd -S), check SSH logs.
Tip: adduser (Debian/Ubuntu) is often more user-friendly than useradd.
Q54. Cannot switch user using su — “Authentication failure”.
Scenario: su – otheruser fails even with correct password.
Root Cause: Incorrect password, account locked, user not in wheel group (if su restricted via PAM), PAM config issue.
Solution: Verify password, check account status (passwd -S), check if user needs to be in wheel group (check /etc/pam.d/su), check auth logs.
Tip: sudo -i -u otheruser is often preferred over su, using sudoer’s credentials.
Q55. A user needs temporary root privileges without knowing the root password.
Scenario: Need granular privilege elevation without full root/sudo access.
Root Cause: Need for specific command elevation.
Solution: Use sudo visudo to configure specific command access for the user, potentially with NOPASSWD: for specific safe commands. E.g., username ALL = /usr/sbin/service apache2 restart.
Tip: Grant least privilege necessary. Use command aliases in sudoers for clarity.
Q56. User’s home directory permissions are incorrect, causing login or application issues.
Scenario: Graphical login fails, apps can’t save settings, SSH keys fail.
Root Cause: Incorrect owner/perms on /home/username or subdirs like ~/.ssh, ~/.config.
Solution (as root): Reset ownership (sudo chown -R user:group /home/user), set base perms (sudo chmod 700 /home/user), fix specific dirs (chmod 700 ~/.ssh, chmod 600 ~/.ssh/*).
Tip: Avoid running GUI apps with sudo, which can mess up home dir ownership.
Q57. Need to find all files owned by a specific user.
Scenario: Need to list/process files owned by a user (e.g., before deletion).
Root Cause: Requirement for ownership-based file searching.
Solution: Use find: sudo find / -user <username> -ls or sudo find /home -user <username> -type f. Add -xdev to stay on one filesystem.
Tip: Narrow search path from / if possible.
Q58. User deleted with userdel but their files still exist.
Scenario: userdel username used, but files owned by their UID remain.
Root Cause: userdel without -r only removes account info, not files.
Solution: Use userdel -r username initially. If already deleted, find files by UID: sudo find / -uid <numeric_UID> or sudo find / -nouser. Then delete or chown the found files.
Tip: Use userdel -r cautiously (backs up first!). Finding by UID is key after deletion.
VI. Processes & Services
Q59. How to list all running processes.
Scenario: Need a view of all executing processes.
Root Cause: Basic process monitoring requirement.
Solution: ps aux (common), ps -ef (alternative format), top/htop (interactive), pstree (tree view).
Tip: Combine ps with grep to find specific processes.
Q60. “Text file busy” when replacing a binary.
Scenario: Trying to overwrite an in-use binary results in Text file busy error.
Root Cause: The binary is still being executed by a running process.
Solution:
Identify process: fuser binaryfile or lsof binaryfile
Kill the process: kill -9 PID (Use with caution)
Replace binary safely.
Tip: Use safer deployment methods like versioned binaries + symlinks to avoid runtime issues.
Q61. Need to find out which process is listening on a specific port.
Scenario: Service fails “port already in use”, or need to identify listener on port X.
Root Cause: Another process has already bound the port.
Solution: Use sudo ss -tlpn | grep :<port> (TCP) or sudo ss -ulpn | grep :<port> (UDP). Older netstat works too. Output shows PID. Use ps aux | grep <PID> for details.
Tip: ss is generally preferred over netstat.
Q62. A process is consuming 100% CPU and needs to be stopped.
Scenario: top/htop shows a process using 99-100% CPU.
Root Cause: Runaway process, infinite loop, intensive task.
Solution: Identify PID (top). Try graceful kill (kill <PID>). Force kill if needed (kill -9 <PID>). Investigate cause.
Tip: Use kill -TERM (15) before resorting to kill -KILL (9).
Q63. Multiple zombie processes accumulate.
Scenario: ps aux shows <defunct> processes.
Root Cause: Parent process failed to wait() for child termination.
Solution:
Identify parent: ps -o ppid= -p <zombie_PID> or use pstree.
Restart or kill the parent process.
Tip: Zombies don’t consume resources but indicate potential bugs in the parent application.
Q64. A critical service (e.g., database, web server) failed and did not restart automatically.
Scenario: Service crashed, but systemd didn’t restart it.
Root Cause: Service unit file missing Restart= directive or set to no.
Solution: Edit service unit (sudo systemctl edit myservice.service). Add [Service] section with Restart=on-failure or Restart=always. Reload daemon (sudo systemctl daemon-reload), restart service.
Tip: Use on-failure generally. Consider RestartSec= delay.
Q65. Systemd service goes into a failed state immediately after starting.
Scenario: systemctl start myservice fails instantly, status shows Active: failed.
Root Cause: Config error, missing dependency, permission issue, process error.
Solution: Check service logs (journalctl -u myservice.service), check specific app logs (/var/log/…), validate config syntax (nginx -t, etc.), check file permissions, check systemctl status output for hints.
Tip: Use systemd-analyze verify <unit_file> to check unit file syntax.
Q66. Need to run a command in the background and ensure it keeps running after logout.
Scenario: Start long task via SSH, want it to continue after disconnect.
Root Cause: Shell exit sends SIGHUP to child processes.
Solution: Use nohup command & (output to nohup.out). Use screen or tmux (start session, run command, detach). Use systemd-run –user … command.
Tip: screen/tmux are more flexible for reattaching and interaction.
Q67. A cron job is not running as scheduled.
Scenario: Script in crontab doesn’t execute.
Root Cause: Cron daemon not running, syntax error, PATH issues, permissions, wrong working dir.
Solution: Check cron status (systemctl status cron), check logs (grep CRON /var/log/syslog), verify syntax (crontab -l), use absolute paths in command, check script permissions (chmod +x), redirect output for debugging (… >> /tmp/job.log 2>&1).
Tip: Cron has minimal environment; define variables or use absolute paths.
Q68. A systemd timer unit is not triggering its associated service.
Scenario: .timer unit exists but corresponding .service never runs.
Root Cause: Timer not enabled/started, syntax error, .service missing/masked, incorrect time spec.
Solution: Check timer status (systemctl status myjob.timer), list timers (systemctl list-timers), enable/start timer, verify unit file syntax (Unit=, OnCalendar=), check associated service status, check journald logs.
Tip: Use systemd-analyze calendar ‘<OnCalendar_spec>’ to test time specs.
Q69. Need to limit the resources (CPU, memory) used by a specific process or user.
Scenario: Non-critical job impacting performance.
Root Cause: Need for resource control.
Solution: Use nice/renice (CPU priority). Use cpulimit (CPU % limit). Use cgroups via systemd (systemd-run –slice=… -p CPUQuota=… -p MemoryMax=…). Use ulimit / /etc/security/limits.conf (per-user PAM limits).
Tip: cgroups (via systemd) offer the most powerful and flexible control. nice only affects priority.
VII. Shell & Scripting
Q70. Shell script works when run manually, but fails when run via cron.
Scenario: Script OK in shell, fails in cron.
Root Cause: Minimal cron environment (PATH, variables), relative paths, permissions.
Solution: Use absolute paths for commands/files, define ENV variables in script/crontab, cd to working dir in script, redirect output to log (>> /tmp/log 2>&1).
Tip: Test script in minimal environment: env -i /bin/bash script.sh.
Q71. Command substitution ($(command) or “) behaves unexpectedly.
Scenario: Using command output as args/vars fails with spaces/special chars.
Root Cause: Unquoted substitution undergoes word splitting and globbing.
Solution: Always double-quote command substitutions: var=”$(command)”, cmd “$(command)”. For multi-line/word processing, use while read or arrays (mapfile).
Tip: Prefer $(…) over backticks. Double quotes are crucial.
Q72. grep not finding a pattern that is visibly present in the file.
Scenario: grep “pattern” file finds nothing, but cat file shows it.
Root Cause: Case sensitivity, regex special chars, file encoding, hidden chars/whitespace.
Solution: Try grep -i (ignore case), grep -F (fixed string), escape regex chars (\.), check encoding (file file.txt, try grep -a), view hidden chars (cat -A).
Tip: Start with -i and -F. Use regex testers.
Q73. Need to process lines of a file reliably in a shell script.
Scenario: for line in $(cat file) messes up lines with spaces.
Root Cause: for … in $(cat) does word splitting, not line splitting.
Solution: Use a while read loop: while IFS= read -r line; do process “$line”; done < file.txt.
Tip: Avoid shell loops for text processing if awk/sed/grep can do it more efficiently.
Q74. Shell script exits unexpectedly when a command fails.
Scenario: Script stops on first command with non-zero exit status.
Root Cause: set -e is active.
Solution: Remove set -e. Or, allow specific command failure: command_that_might_fail || true. Or, check explicitly: if ! command_that_might_fail; then …; fi.
Tip: Understand set -e behavior or handle errors explicitly. set -eo pipefail is common.
VIII. Hardware & Kernel
Q75. System doesn’t recognize newly added hardware (e.g., USB drive, NIC).
Scenario: Plugged in hardware is not visible/usable.
Root Cause: Missing/unloaded kernel driver, faulty hardware, power issue, conflict.
Solution: Check connection, check dmesg for errors/detection messages, get hardware ID (lspci -nn, lsusb), search for drivers, try manual load (modprobe), update kernel/system, check firmware needs (dmesg).
Tip: dmesg is the first place to look. Search online for “Linux driver <VendorID> <DeviceID>“.
Q76. Kernel panic occurs during boot or randomly.
Scenario: System halts with “Kernel panic – not syncing: …” message.
Root Cause: Severe error: Hardware failure (RAM, CPU, disk), corrupted kernel/initramfs, bad driver, filesystem corruption.
Solution: Note error message, test hardware (memtest86+, SMART), boot older kernel, boot rescue mode (run fsck, check logs), reinstall kernel/rebuild initramfs (update-initramfs, dracut), try minimal boot parameters (nomodeset).
Tip: Persistent panics often point to hardware issues.
Q77. High number of interrupts reported in /proc/interrupts.
Scenario: Sluggish system, cat /proc/interrupts shows rapidly increasing IRQ count for a device.
Root Cause: Faulty hardware, buggy driver (interrupt storm), misconfiguration, legitimate high load.
Solution: Identify device from /proc/interrupts, monitor rate (watch), update driver/kernel, check dmesg, disable device/unload module to test, check IRQ sharing.
Tip: Interrupt storms severely impact performance. Identifying the source device is key.
Q78. Need to adjust kernel parameters using sysctl.
Scenario: Need to tune kernel behavior (e.g., vm.swappiness, net.ipv4.ip_forward).
Root Cause: Modify runtime kernel parameters via /proc/sys/.
Solution: View value (sysctl <param>), change temporarily (sudo sysctl -w <param>=<value>), make persistent by adding <param> = <value> to /etc/sysctl.conf or /etc/sysctl.d/*.conf and run sudo sysctl -p or sudo sysctl –system.
Tip: Test changes carefully. Document persistent changes.
Q79. dmesg output is flooded with specific hardware error messages.
Scenario: dmesg shows thousands of repeating errors (ATA, USB, PCIe).
Root Cause: Failing hardware, incompatibility, driver bug, power issue.
Solution: Identify device from error message, check connections, update firmware/BIOS, update kernel/drivers, test hardware (remove/replace, diagnostics), check power supply.
Tip: Flooding dmesg impacts performance. Address the root cause. Kernel parameters might offer workarounds.
Q80. “No such file or directory” when executing a binary.
Scenario: A binary file exists, but running it gives “No such file or directory”.
Root Cause: Missing dependent shared libraries (most common), or wrong binary compiled for another architecture (e.g., running ARM binary on x86_64).
Solution:
Check dynamic dependencies: ldd ./binaryfile. Look for “not found”.
Install missing libraries (use package manager).
Check file architecture: file ./binaryfile. Ensure it matches system arch (uname -m).
Tip: Always compile binaries on the target OS/architecture or ensure compatibility. Use ldd for library issues.
IX. Security
Q81. Suspected unauthorized login attempts found in logs.
Scenario: Logs show many failed logins (e.g., SSH).
Root Cause: Brute-force attack targeting exposed services.
Solution: Check auth logs (/var/log/auth.log, /var/log/secure, lastb), identify source IPs, review successful logins (last). Implement fail2ban, enforce strong passwords, use SSH key auth only (PasswordAuthentication no), restrict access via firewall, consider changing SSH port.
Tip: Monitor logs regularly. fail2ban is essential for public servers.
Q82. Need to securely transfer files between two Linux servers.
Scenario: Need encrypted and authenticated file transfer.
Root Cause: Requirement for secure protocol (not FTP/telnet).
Solution: Use scp (Secure Copy): scp file user@host:/path/. Use rsync over SSH (default): rsync -avz dir/ user@host:/path/.
Tip: rsync is generally preferred for directories/backups due to efficiency and resume capability.
Q83. How to secure the SSH daemon configuration (sshd_config).
Scenario: Need to harden SSH server settings.
Root Cause: Defaults may allow insecure practices.
Solution: Edit /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no (use keys!), Protocol 2, AllowUsers/AllowGroups, consider Port, MaxAuthTries. Restart sshd.
Tip: Test changes carefully to avoid lockout. Use sshd -t to check syntax.
Q84. Firewall rules seem incorrect or too permissive.
Scenario: Concern about unnecessary open ports or allowed traffic.
Root Cause: Open default policy, poorly configured rules.
Solution: Identify firewall (iptables -L, nft list ruleset, firewall-cmd –list-all, ufw status), review rules (look for INPUT ACCEPT, overly broad sources 0.0.0.0/0), apply least privilege (default deny INPUT), modify rules using correct tool (iptables, nft, firewall-cmd, ufw), verify with nmap externally.
Tip: Adopt default-deny INPUT policy. Document allowed rules.
Q85. SELinux or AppArmor is blocking a service from working correctly.
Scenario: Service fails (start, file access, port bind) despite correct file permissions.
Root Cause: Mandatory Access Control (MAC) policy violation.
Solution: Check MAC status (sestatus, aa-status), check audit logs (ausearch -m avc, journalctl -g apparmor, /var/log/audit/audit.log), interpret denial message. Fix by: temporary permissive mode (testing only!), adjusting policy (audit2allow, edit profiles), restoring file contexts (restorecon), using correct paths/ports allowed by policy, setting SELinux booleans (setsebool).
Tip: Check audit logs first! Avoid fully disabling MAC; learn to adjust policies.
Q86. Checking file integrity on the system.
Scenario: Need to verify if system files have been tampered with.
Root Cause: Security requirement to detect unauthorized modification.
Solution: Use package manager verification (rpm -Va, dpkg –verify / debsums). Use File Integrity Checkers like AIDE or Tripwire (install, initialize baseline database, run checks aide –check, update baseline after legitimate changes aide –update).
Tip: Run checks regularly. Securely store the initial baseline database off-system. Investigate all reported changes.
Q87. Setting password complexity and expiration policies.
Scenario: Need to enforce strong passwords and regular changes.
Root Cause: Default policies often weak; need PAM configuration.
Solution: Configure PAM (/etc/pam.d/passwd, /etc/pam.d/system-auth, etc.) using pam_pwquality or pam_cracklib (options: minlen, dcredit, ucredit, ocredit, etc.). Configure expiration in /etc/login.defs (PASS_MAX_DAYS, PASS_WARN_AGE). Use chage for existing users.
Tip: Test PAM changes carefully. Refer to man pam_pwquality.
Q88. Auditing user commands or specific file access.
Scenario: Need to log specific user commands or access to critical files.
Root Cause: Security/compliance requirement for detailed logging.
Solution: Install/configure auditd. Define rules in /etc/audit/rules.d/ (e.g., -w /etc/passwd -p wa -k key, -a always,exit -F arch=b64 -S execve -F auid=UID -k key). Load rules (augenrules –load or restart auditd). Search logs with ausearch -k key.
Tip: Audit rules can be very verbose. Be specific. Ensure log rotation/space. Use keys (-k) for searching.
Q89. User accidentally downloaded and ran a malicious script.
Scenario: User ran untrusted script; suspicious activity observed.
Root Cause: Malware execution.
Solution: Act Fast! 1. Isolate machine (disconnect network). 2. Identify (login locally, check processes ps, top, network ss, history, cron, new/modified files). 3. Contain/Eradicate (kill process, remove files/cron/units, change passwords). 4. Analyze (optional: preserve disk image). 5. Recover (restore from backup, consider rebuild).
Tip: Prevention is key (education, updates, firewalls). Isolate immediately. Rebuild may be safest if compromised.
X. Package Management
Q90. apt update or yum check-update fails with repository errors.
Scenario: Package list update fails (“Could not resolve”, “404”, “NO_PUBKEY”).
Root Cause: Network issue (DNS, firewall, proxy), bad repo URL, repo down/moved (EOL), missing GPG key, wrong system clock.
Solution: Check network, verify repo URLs (sources.list, yum.repos.d), check repo status online, fix GPG keys (import missing key), check system time (date).
Tip: Check network basics first. Error messages give clues (URL, key ID).
Q91. Package installation fails due to dependency conflicts or unmet dependencies.
Scenario: apt/yum install fails reporting conflicts or unmet deps.
Root Cause: Incompatible versions needed, mixing repos, broken package DB, dependency missing.
Solution: Read error message, try fix broken (apt –fix-broken install), disable third-party repos, resolve specific conflicts (remove old, install specific version), search for alternate package names, clean cache (apt clean).
Tip: Avoid mixing major release repos. aptitude might offer better resolution.
Q92. Need to find which installed package owns a specific file.
Scenario: Need to know which package installed /usr/bin/command or /etc/config.
Root Cause: Trace file origin for troubleshooting/removal.
Solution: DPKG: dpkg -S /path/to/file. RPM: rpm -qf /path/to/file. To find available package: apt-file search file (needs install/update), yum provides file.
Tip: Useful for identifying source of configs/binaries.
Q93. System has mixed packages from different distribution versions or repositories.
Scenario: System unstable, complex dependency issues, “dependency hell”.
Root Cause: Installing from incompatible sources.
Solution: Difficult. Identify foreign packages (check repo origin in apt policy / yum list installed), configure repository pinning/priorities, attempt downgrade (apt install pkg/stable, yum downgrade pkg), backup data. Reinstall often cleanest solution.
Tip: Be cautious with third-party repos. Use backports, containers, or compile locally instead of mixing core repos.
Q94. Uninstalling a package left its configuration files behind.
Scenario: apt/yum remove used, but configs remain in /etc.
Root Cause: remove often keeps configs intentionally.
Solution: APT: use sudo apt purge <package> to remove package + configs. Find already removed (rc state): dpkg -l | grep ‘^rc’. Yum/DNF: usually removes configs unless modified; manually delete if needed.
Tip: Use purge if configs definitely not needed. Check /etc after removal if unsure.
XI. Logging & Monitoring
Q95. Deleted /var/log/messages log file by mistake.
Scenario: Important system logs removed; logging services may fail.
Root Cause: Services like rsyslogd or journald rely on files under /var/log.
Solution:
Restart syslog service: sudo systemctl restart rsyslog (or systemd-journald)
Log files will often be recreated automatically.
Tip: Avoid manually deleting log files; use logrotate to manage logs safely.
Q96. Log files in /var/log are growing too large and filling the disk.
Scenario: /var/log partition full due to large log files.
Root Cause: Log rotation misconfigured or failing. Excessive logging.
Solution: Check logrotate config (/etc/logrotate.conf, /etc/logrotate.d/*), ensure directives (rotate, size, daily, compress) are correct. Debug (logrotate -d), force run (logrotate -f). Check cron job. Reduce service log verbosity. Temporary: truncate (truncate -s 0), compress/remove old rotated logs.
Tip: Enable compress in logrotate. Review configs regularly.
Q97. Journald logs (journalctl) are consuming too much disk space.
Scenario: journalctl –disk-usage shows large size in /var/log/journal or /run/log/journal.
Root Cause: Default retention too high, excessive logging.
Solution: Configure limits in /etc/systemd/journald.conf (SystemMaxUse=, RuntimeMaxUse=, MaxRetentionSec=). Restart systemd-journald. Manually vacuum (journalctl –vacuum-size=, journalctl –vacuum-time=). Reduce service verbosity.
Tip: Set SystemMaxUse= to cap disk usage. Ensure /var/log/journal exists for persistence.
Q98. How to filter specific messages from journalctl or standard log files.
Scenario: Need to find specific errors, service logs, or time ranges.
Root Cause: Need efficient log querying.
Solution: journalctl: use flags -u <unit>, _PID=, _UID=, –since, –until, -p <priority>, -f (follow), -k (kernel). Combine flags. Traditional logs (/var/log/*): use grep (with -i, -C, -E), tail (-n, -f), less (interactive search /), awk, sed.
Tip: journalctl offers powerful structured filtering. grep is essential for text files. Pipe tools together (cat file | grep | awk).
Q99. How to monitor system performance metrics (CPU, memory, I/O) historically.
Scenario: Need performance trends over time, not just real-time.
Root Cause: Requirement for historical performance logging.
Solution: Use sar (System Activity Reporter from sysstat package). Install/enable sysstat. View reports: sar (today CPU), sar -r (memory), sar -b (I/O), sar -f /var/log/sysstat/saDD (specific day). Use dedicated monitoring systems (Prometheus+Grafana, ELK, Zabbix) for advanced features.
Tip: sar is great for on-server history. Use dedicated stacks for long-term, multi-system monitoring.
Q100. Need to centralize logs from multiple servers to a single location.
Scenario: Managing logs individually is inefficient.
Root Cause: Need for centralized log management.
Solution: Set up central log server (rsyslog, syslog-ng, ELK, Graylog). Configure clients (senders) to forward logs via syslog protocol (UDP/TCP/TLS) or journald upload. E.g., in client /etc/rsyslog.conf: *.* @@central-log-server:6514 (TLS). Restart services. Verify logs arrive centrally.
Tip: Use TCP/TLS for reliable/secure forwarding. Consider structured formats (JSON).
Conclusion:
This list of 100 Linux Scenario-Based Questions and Answers offers a deep dive into the practical realities of Linux system administration and DevOps. It systematically addresses common pain points across:
Filesystems & Permissions: Resolving access issues, managing disk space and inodes, handling file operations safely.
Performance & Resources: Diagnosing CPU, memory, and I/O bottlenecks, managing processes and swap.
Networking: Troubleshooting connectivity, DNS, firewall rules, and service accessibility.
User Management & Security: Handling user accounts, sudo privileges, SSH hardening, MAC systems (SELinux/AppArmor), and basic incident response.
Services & Processes: Managing systemd units, cron jobs, background tasks, and resource limits.
Package Management: Dealing with repositories, dependencies, and file ownership.
Logging & Monitoring: Utilizing journalctl, logrotate, sar, and centralizing logs.
By emphasizing root cause analysis alongside specific, actionable solutions and best-practice tips, this collection serves as an excellent reference guide, study aid, and practical toolkit for anyone seeking to enhance their Linux troubleshooting capabilities and operational proficiency.
Linux Complete Tutorial by TechCarrerHubs.
For more information about Job Notifications, Open source Projects, Tech updates and Interview questions, please stay tuned TechCareerHubs official website.
