Linux File Systems and Permissions Questions

Comprehensive coverage of Linux file system internals, the standard filesystem hierarchy, practical administration tasks, and the permission and access control model. Candidates should understand the purpose of directories such as /etc, /var, /usr, /home, /tmp, and /opt; how files and directories are represented by inodes and directory structures; the role of file descriptors; and how mounts and different filesystem types and mount options affect behavior and available features. Practical skills include creating deleting moving copying and renaming files and directories; managing symbolic links and hard links; mounting and unmounting filesystems and configuring persistent mounts; checking disk usage and block device information; and basic backup restore and integrity check workflows. Permission and access control topics include user group and other classes; read write and execute bits and octal notation; special permission bits such as set user id set group id and the sticky bit; default creation mask and umask; ownership management with chown and chgrp; permission changes with chmod; and the use of access control lists for fine grained permissions when supported. The topic also encompasses user and group management as it relates to file ownership and access control including adding and removing users and groups managing group membership sudo configuration and the role of system account files such as /etc/passwd /etc/shadow and /etc/group. Interview assessment typically focuses on practical commands and procedures diagnosing permission related failures reasoning about secure defaults and trade offs between security and usability and designing safe backup mount and maintenance strategies.

MediumTechnical

49 practiced

Compare ext4, XFS, Btrfs and ZFS in terms of: online resize support, snapshot capability, metadata reliability, repair tools, and suitability for high IOPS workloads vs archival storage. As an SRE, which filesystem would you choose for a high-throughput event store and why?

Sample Answer

Brief comparison (ext4, XFS, Btrfs, ZFS) by requested axes, then my SRE choice for a high‑throughput event store.

Online resize support- ext4: online grow for mounted filesystems (resize2fs), offline shrink only. - XFS: online grow supported; shrink unsupported. - Btrfs: online grow/shrink supported (flexible). - ZFS: online grow (zpool add/replace); shrinking a pool is generally not supported.

Snapshot capability- ext4: none built-in (LVM or filesystem-level tooling required). - XFS: no native snapshots; does support snapshots via LVM or flashcache/COW layers. - Btrfs: built-in lightweight writable/read-only snapshots. - ZFS: first-class snapshotting with efficient clones and rollbacks.

Metadata reliability- ext4: journaled metadata (good reliability). - XFS: journaling with robust metadata structures, reliable at scale. - Btrfs: copy-on-write (COW) metadata with checksums — stronger integrity but historically had stability bugs. - ZFS: COW + end-to-end checksums + copy-on-write transactional model — highest metadata integrity.

Repair tools- ext4: fsck (mke2fs/fsck), mature and fast on moderate sizes. - XFS: xfs_repair (fast but can require unmount or special options); well-tested. - Btrfs: btrfs scrub/ck; repair tooling exists but partial and historically less mature. - ZFS: self-healing with checksums and redundancy; zpool scrub and resilient repair via redundancy (RAIDZ/Mirror).

Suitability: high IOPS vs archival- High IOPS: ext4 or XFS (lower overhead, predictable latency). XFS scales well for large files/concurrent workloads. - Archival / data integrity focus: ZFS (snapshots, checksums) or Btrfs (if you need kernel integration and lighter weight), with ZFS preferred for production-grade integrity.

SRE choice for a high-throughput event storeI would choose XFS on Linux (or ext4 if simpler) for the event store. Reasoning: event stores require very high write throughput, low and predictable latency, and good concurrency. XFS scales well with many threads, handles large files and metadata efficiently, supports online growth, and has mature tooling. Pair XFS with proper RAID (or use hardware/NVMe RAID), tuned mount options (noatime, allocsize, stripe alignment), and use an append-friendly layout (preallocate files, O_DIRECT or tuned fsync strategy) plus rigorous monitoring and backups (snapshots via LVM if needed). If the primary requirement shifted to absolute data integrity and snapshots for versioning, I’d evaluate ZFS despite higher memory and CPU costs.

MediumTechnical

42 practiced

Design a permissions model for /srv/projects where multiple teams need write access to their own project directories but must not access other teams' data. Use POSIX ACLs and default ACLs to show how you would set this up and how to ensure new files inherit desired ACLs.

Sample Answer

Situation: We need /srv/projects so each team (teamA, teamB, ...) can read/write only their own project directory but not other teams’ data. We'll use POSIX ACLs + SGID to ensure group ownership and default ACLs to make new files inherit correct permissions.

Steps & commands:1. Create groups and project dirs- groupadd teamA && groupadd teamB- mkdir -p /srv/projects/teamA /srv/projects/teamB

2. Set ownership and SGID so new files inherit group- chown root:teamA /srv/projects/teamA- chmod 2770 /srv/projects/teamA(2770 = rwxrws---: owner rwx, group rw s (SGID), others none)

3. Apply POSIX ACLs and default ACLs so members get rwx on new items- setfacl -R -m g:teamA:rwx,o::--- /srv/projects/teamA- setfacl -R -m d:g:teamA:rwx,d:o::--- /srv/projects/teamAExplanation: the first sets current ACLs; the second sets default ACLs (d:...) that are inherited by newly created files/dirs.

4. Repeat for teamB:- chown root:teamB /srv/projects/teamB- chmod 2770 /srv/projects/teamB- setfacl -R -m g:teamB:rwx,o::--- /srv/projects/teamB- setfacl -R -m d:g:teamB:rwx,d:o::--- /srv/projects/teamB

Verify:- getfacl /srv/projects/teamAExample excerpt:# file: /srv/projects/teamA# owner: root# group: teamAuser::rwxgroup::rwxother::---default:user::rwxdefault:group::rwxdefault:other::---

Notes, edge cases & best practices:- Ensure users are members of their team group (usermod -aG teamA alice).- SGID ensures new files/dirs inherit the team group; default ACLs ensure the group gets rwx on new items regardless of creator umask.- If a user belongs to multiple groups, primary vs supplementary group affects newly created file group—SGID and default ACLs mitigate most issues.- On NFS-exported filesystems, confirm server supports POSIX ACLs; NFSv4 ACLs differ.- To apply ACLs to existing files recursively and force defaults: setfacl -R -m d:g:teamA:rwx /srv/projects/teamA- Keep an admin/backdoor group (e.g., ops) granted as needed: setfacl -m g:ops:rwx,d:g:ops:rwx /srv/projects/*

This setup isolates team data while ensuring any new file/dir inherits proper access automatically.

HardTechnical

55 practiced

Design an SLO-driven change management policy for filesystem and permission changes affecting production services. Include how to set SLOs and error budgets for permission-change-induced incidents, approval/rollback criteria, and automation guardrails an SRE team should put in place.

Sample Answer

Situation: Filesystem and permission changes have caused production outages in the past (e.g., accidental chmod/chown or ACL misconfig), so we need an SLO-driven change policy that minimizes risk while enabling necessary maintenance.

Policy summary:- Goal: Protect availability and correctness SLOs for services that depend on files/ACLs while keeping change velocity.

1) Set SLOs & error budgets- Identify dependent services and their user-visible SLOs (e.g., 99.95% availability, 99.9% read-correctness).- Create a Permission-Change Impact SLO: percentage of permission-change deployments that do not cause a degradations >= severity-2 within a 30-day window. Example target: 99.9% safe-change rate.- Map error budget: translate allowed SLO breach into an error budget for permission changes (e.g., 0.1% of permission-change operations per month may cause incidents). Track consumption per service and org.

2) Approval criteria (gates)- Low-risk changes (non-prod only, no ACL expansion, no world-writable): auto-approve with CI checks.- Medium-risk (production but limited scope, read-only to subset): require peer review + change owner sign-off + test in staging that simulates permissions.- High-risk (root-level, wide ACL updates, org-wide file servers): require SRE approval, runbook, canary plan, and scheduled maintenance window.

3) Rollback criteria & runbook- Define automated health checks that evaluate SLOs and critical manifests (process restarts, error rates, permission-denied logs) for 15 minutes post-change.- Rollback triggers: >25% of error budget for the service consumed within 24h by this change, or any increase in permission-denied errors above baseline threshold, or user-facing error rate spike >X%.- Rollback actions: automated revert of permission change via idempotent script, reapply previous ACL snapshot, alert on-call, create incident ticket.

4) Automation guardrails- Mandatory pre-change validation: - Static analysis of ACL diffs to detect broad grants (e.g., ANY/ALL principals, world-write). - Simulation tools that run daemonized test agents to assert access paths for representative principals. - Dry-run mode that produces permission audit and expected denials.- Canary rollout: - Gradual % of hosts/users (e.g., 1%, 10%, 100%) with automated metric gating. - Circuit breaker: stop and rollback if gating metrics breach thresholds.- Immutable, auditable change artifacts: - All permission changes recorded in a git-backed ACL repo, signed commits, CI pipeline runs, and timestamped approvals.- Enforcement via tooling: - RBAC for the change tool; only automation/service accounts can perform bulk changes. - Rate-limiting of permission-change jobs to avoid blast radius. - Automated snapshots/backups of ACL state before apply; easy one-click revert.- Observability: - Dedicated dashboards showing permission-denied counts, service error rates, and change events; alert rules tied to rollback triggers. - Post-change automated report sent to stakeholders summarizing impact and error budget consumption.

5) Governance & continuous improvement- Error-budget-driven discipline: if permission-change error budget is exhausted for a service, freeze non-critical permission changes and require a postmortem for each subsequent change.- Blameless postmortems for any rollback or incident; capture root cause and adjust SLOs, tests, or gates.- Quarterly review of SLO targets and guardrails based on incident trends.

Why this works:- Quantifies risk via SLO/error budget so decisions are data-driven.- Combines automation (speed, reproducibility) with human gates where risk is high.- Ensures fast rollback and learnings to reduce future risk while preserving throughput of safe changes.

HardSystem Design

45 practiced

Design a read-only root filesystem strategy with writable overlays for servers to improve immutability and rollback capability. Discuss approaches (overlayfs, unionfs, ostree, container-style immutable images), how to manage package updates, how to rollback, and how to handle /var and /etc being writable when necessary.

Sample Answer

Requirements:- Immutable root to reduce configuration drift and improve security- Fast, reliable rollback to known-good image- Writable areas for state (/var, /run, /tmp) and controlled /etc changes- Minimal boot-time complexity, integratable with config management and monitoring

High-level options (trade-offs):- OverlayFS/UnionFS: Apply a read-only base image (squashfs or ext4 loop) with an upper writable layer per host. Low-level, flexible, good performance. Rollback = discard upper layer. Downsides: lifecycle management of base images and upgrades handled externally.- ostree: Git-like immutable filesystem trees. Atomic upgrades, bootable rollbacks via bootloader entries, fine for OS/package management. Strong for system immutability and transactional updates.- Container-style immutable images (OCI, rkt): Use image layers and run processes inside systemd-nspawn or container runtime. Good isolation; needs init integration for host services.- UnionFS+package manager: Combine with deb/rpm layering (e.g., rpm-ostree) to get package semantics.

Recommended design (SRE-friendly):1. Base image stored as signed squashfs or ostree commit in artifact registry.2. Bootloader configured with two boot entries (current / fallback). Use initramfs to mount base as read-only and mount overlayfs upper with host-specific writable dir (e.g., /var/lib/overlay/<node-id>).3. Writable paths: - /var, /run, /tmp => mounted as tmpfs or bind-mounts to persistent per-host directories in the upper layer. - /etc => treat as layered: /etc from base (immutable) with /etc/override (upper) merged via etcd/consul-template or kexec-enabled overlay for ephemeral changes. Prefer managing desired /etc via config management and avoid manual edits; persist overrides under /etc/overrides and track them in Git.4. Package updates: - Use ostree/rpm-ostree for transactional upgrades when possible. Otherwise produce new immutable image artifacts (CI builds) and promote via automated rollout. - Staged rollout: Canary group -> metrics check -> progressively increase. Use health checks and automated rollback triggers.5. Rollback: - If ostree/rpm-ostree: bootloader records last good; rpm-ostree rollback or ostree admin rollback is atomic. - If overlayfs+squashfs: keep previous image on disk and switch bootloader entry (or flip symlink) to prior image; discard or archive upper layer. - Automate via orchestration tool (Ansible/Terraform/Cluster manager) to perform remote reboot into fallback and validate services.6. Observability & safety: - Health probes, automated canary analysis, metrics rollback policies. - Ensure ephemeral state separation and backups for persistent data stores (databases should be external).7. Edge cases: - Kernel/module updates require reboot; plan maintenance windows or livepatch where possible. - Host-specific secrets: mount from TPM/HashiCorp Vault at boot into tmpfs; avoid storing secrets in overlays.

Summary:- For full atomic package semantics and easiest rollback: use ostree/rpm-ostree.- For simpler adoption on existing fleets: read-only squashfs + overlayfs upper per-host with CI-built images and automated boot-switching.- Always separate state, automate promotion/rollback, sign images, and monitor health to make immutability and rollback reliable in production.

EasyTechnical

43 practiced

Practical file operations: you're asked to move /var/www/myapp to /mnt/fast-storage while preserving permissions, ACLs, extended attributes, and SELinux contexts with minimal downtime. What commands or sequence would you use on a Linux host? Explain why you chose those commands and mention safety measures (verification, dry-run, backup).

Sample Answer

Approach (brief): Use rsync to copy while preserving ownership, perms, ACLs, xattrs and minimizing downtime by doing an initial background sync, stopping the app, then a fast final sync and switch. Verify SELinux with restorecon/ls -Z and keep a backup/snapshot.

Commands and sequence:

1) Prepare and test- Ensure target mounted and has enough space:

bash

df -h /mnt/fast-storage
mount | grep /mnt/fast-storage

- Dry-run initial sync to validate options:

bash

rsync -aAXH --numeric-ids --delete --progress --dry-run /var/www/myapp/ /mnt/fast-storage/myapp/

2) Initial copy (while app is live)

bash

rsync -aAXH --numeric-ids --delete --progress /var/www/myapp/ /mnt/fast-storage/myapp/

Flags explained:- -a archive (recursive, preserve basic attrs)- -A preserve ACLs- -X preserve extended attributes (xattrs)- -H preserve hard links- --numeric-ids keep uid/gid numbers- --delete keep target in sync

3) Prepare for cutover (minimal downtime)- Stop the web app / put into maintenance mode (short window):

bash

systemctl stop myapp.service
# or touch maintenance flag so app returns 503

4) Final (fast) sync to capture deltas

bash

rsync -aAXH --numeric-ids --delete --progress --omit-dir-times /var/www/myapp/ /mnt/fast-storage/myapp/

Optional: add --checksum for extra verification (slower).

5) SELinux contexts- Reapply or verify contexts on the new path:

bash

# If rsync preserved xattrs/context, verify:
ls -lZ /mnt/fast-storage/myapp | head
# Otherwise re-label:
restorecon -R -v /mnt/fast-storage/myapp

6) Swap and start- Move mount point or update app config to point to /mnt/fast-storage/myapp, or bind-mount:

bash

mount --bind /mnt/fast-storage/myapp /var/www/myapp
# or move and symlink after ensuring everything is correct
systemctl start myapp.service

Verification & safety measures- Dry runs with --dry-run before any real copy.- Run initial rsync while live, then final rsync after stop to minimize downtime.- Backups: take LVM/ZFS snapshot of /var/www (or tar/rsync backup) before operations:

bash

tar -czf /root/myapp-backup-$(date +%F).tar.gz /var/www/myapp

- Verify ACLs/xattrs: getfacl and getfattr:

bash

getfacl -R /mnt/fast-storage/myapp | head
getfattr -d -m - -R /mnt/fast-storage/myapp | head

- Verify ownership/permissions and SELinux: ls -lZ and test the app end-to-end; check logs.- Rollback plan: keep original data until confirmed; unmount bind and remount original path or restore from snapshot.

Why rsync: rsync supports ACLs (-A), xattrs (-X), preserves ownership and is incremental so the second sync is fast — ideal for minimal downtime. restorecon ensures SELinux labels are correct if not preserved. Using --numeric-ids avoids mismatches when UIDs/GIDs differ. Dry-runs and snapshots provide safety and quick rollback.

Unlock Full Question Bank

Get access to hundreds of Linux File Systems and Permissions interview questions and detailed answers.

Join thousands of developers preparing for their dream job.