Linux findmnt Command: 43 Examples for Security Audits

Linux findmnt Command Cheat Sheet: Audit Mounts and Spot Suspicious Filesystems

Quick Answer
findmnt shows every mounted filesystem and its options on Linux. Defenders use it to spot unexpected mounts, confirm noexec, nosuid, and nodev hardening, and catch fstab drift during audits and incident response.

Picture a 2 a.m. alert: an EDR tool flags a binary executing out of a temporary directory on a production Linux server. The first instinct is to dig into processes and network connections. A seasoned responder asks a quieter question first: what is mounted here, and with which options? If that temp directory sits on a filesystem without noexec, an attacker's dropped file runs freely. If an unfamiliar network share appears in the mount table, you may be looking at a staging point for data movement.

The command that answers those questions in seconds is findmnt, part of the util-linux package. This guide treats it as a Linux security hardening and incident response tool rather than just a disk utility. You'll get the commands, what to look for in the output, and how to turn a one-off check into a repeatable audit.

Note: the scenario above is illustrative, not a report of a specific incident.

Table of Contents

• Why findmnt matters to defenders
• Reading the mount table
• The path lookup trap: positional argument vs. -T
• Hardening checks: noexec, nosuid, nodev
• Spotting unexpected network mounts
• Catching fstab drift and configuration errors
• Output formats for automation and reporting
• Key indicators to review
• Detection and prevention techniques
• Expert tips
• FAQ
• Conclusion

Why findmnt Matters to Defenders

Mount options are a quiet but effective control layer. Three of them matter most for security:

• noexec prevents direct execution of binaries from the filesystem.
• nosuid ignores setuid and setgid bits, limiting privilege escalation through planted binaries.
• nodev ignores device files, so a crafted device node on a writable partition can't be used to reach hardware.

Benchmarks such as the CIS Benchmarks for many Linux distributions recommend applying restrictive options to world-writable locations like /tmp, /var/tmp, and /dev/shm. That makes mount auditing a routine part of compliance work as well as a hardening step.

Compared with reading /etc/mtab or raw mount output, findmnt gives you a hierarchy, selectable columns, filtering, and machine-readable output. By default it reads the kernel's live mount table, so it reflects what is mounted right now, not what a config file says should be mounted.

Reading the Mount Table

Start with the basics. Run it with no arguments:

findmnt

What it does: prints all mounted filesystems in a tree that shows which mounts sit under others.
When to use it: first-look triage on an unfamiliar host.
Expected output: columns for TARGET, SOURCE, FSTYPE, and OPTIONS, with the root filesystem at the top.

For a flat list that is easier to pipe into other tools:

findmnt -l

To narrow the view to what you care about, choose your own columns:

findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS

This is the single most useful audit view. It maps each backing device to its mount point, filesystem type, and active options. Add UUID or LABEL to the column list when you need to match a device against inventory records:

findmnt -o SOURCE,TARGET,UUID,LABEL

Capacity data is available too, depending on your util-linux version:

findmnt -o TARGET,SIZE,USED,AVAIL,USE%

That helps with an investigation angle people often miss: a log partition at 100% usage may mean logging has stopped, and attackers (or plain misconfiguration) can cause that. For a df-style summary, findmnt --df is also available.

To see every column your installed version supports, use:

findmnt --output-all

If you only want rows without headers, for scripts or quick copy-paste, add -n:

findmnt -n -o SOURCE,TARGET,FSTYPE

To filter by filesystem type, use -t. Multiple types are comma-separated:

findmnt -t ext4
findmnt -t xfs
findmnt -t ext4,xfs

The Path Lookup Trap: Positional Argument vs. -T

This is where many cheat sheets quietly mislead people. Running findmnt /var/log matches /var/log only if it is itself a mount point (or a source or tag). If /var/log is just a directory on the root filesystem, you may get no output at all, which looks like "nothing found" when the real answer is "it lives on /".

To find which filesystem contains a path, use --target (short form -T):

findmnt -T /var/log
findmnt -T /etc/hosts
findmnt -T /home -o TARGET,SOURCE,OPTIONS

What it does: resolves the path to the mount that holds it.
When to use it: during an investigation, when you need to know whether a suspicious file lives on a hardened partition or on a permissive one.
Expected output: one line showing the containing mount, its source device, and its options.

Related lookups use -M for an exact mount point and -S for a source device:

findmnt -M /mnt
findmnt -S /dev/sda1

Also note that /etc/hosts only shows up as its own mount in some environments, such as containers where it is bind-mounted. On a standard host, use -T and expect to see the root filesystem.

Hardening Checks: noexec, nosuid, and nodev

The -O flag filters by mount option, so you can list which mounts carry a given restriction:

findmnt -O noexec
findmnt -O nosuid
findmnt -O nodev
findmnt -O ro
findmnt -O rw

A faster, more targeted check for the usual suspects is to look at the specific paths attackers favor for staging:

findmnt -T /tmp -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T /var/tmp -o TARGET,SOURCE,FSTYPE,OPTIONS
findmnt -T /dev/shm -o TARGET,SOURCE,FSTYPE,OPTIONS

What you want to see depends on your policy, but for these locations most hardening baselines expect nodev, nosuid, and noexec in the OPTIONS column. If /tmp resolves to / with default options, it is sharing the root filesystem and none of those restrictions apply to it.

Caveat worth knowing: noexec is a speed bump, not a wall. Interpreters such as Python or a shell can still run script files from a noexec mount when invoked directly. Treat it as one layer in a defense-in-depth approach, alongside application allowlisting and endpoint detection and response tools.

Spotting Unexpected Network Mounts

Network shares are legitimate in plenty of enterprises, which is exactly why unexpected ones deserve attention. A new share on a server that never needed one can mean misconfiguration, shadow IT, or something worse. List them with:

findmnt -t nfs,nfs4,cifs -o SOURCE,TARGET,FSTYPE,OPTIONS

What to look for: source hosts you don't recognize, shares mounted from outside your expected network ranges, and shares mounted read-write where read-only would do. Compare the result to your asset documentation. Anything that can't be explained deserves a ticket.

Keep in mind that a mount is only visible in the mount namespace of the process you run it from. Containers have their own view, so a clean result on the host doesn't say anything about what is mounted inside a container.

Catching fstab Drift and Configuration Errors

/etc/fstab defines what should mount at boot. The kernel table shows what is mounted. A gap between the two is worth investigating. Pull each view:

findmnt --fstab -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt --kernel -o SOURCE,TARGET,FSTYPE,OPTIONS

The first lists configured entries; the second lists live mounts (the default source). To resolve LABEL= and UUID= tags into device paths for an easier comparison, add --evaluate to the fstab view.

Differences can have ordinary explanations, such as manual mounts by an admin, removable media, or systemd mount units. But a mount that exists live and appears nowhere in your configuration is exactly the kind of thing worth tracing to a person or a process.

Before a reboot or after editing fstab, validate it:

findmnt --verify --verbose

This checks entries for problems such as unreachable devices or malformed options. It is a cheap safeguard against a typo that leaves a server unable to boot cleanly.

Output Formats for Automation and Reporting

When you need to feed mount data into a SIEM pipeline, a compliance script, or a ticket, plain tree output isn't the right format. findmnt offers several:

findmnt --json -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt --pairs -o SOURCE,TARGET,FSTYPE,OPTIONS
findmnt --raw -o SOURCE,TARGET,FSTYPE,OPTIONS

• --json produces structured output that is easy to parse with tools like jq.
• --pairs prints escaped KEY="value" pairs, convenient for shell parsing.
• --raw prints without the usual formatting, useful when whitespace handling matters.

To save a point-in-time snapshot for audit evidence:

findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS > mounts-report.txt

Timestamp these snapshots and store them off-host. A baseline taken from a known-good system turns later comparison into a simple diff.

To show a mount and everything beneath it, use --submounts (short form -R):

findmnt --submounts /mnt
findmnt --submounts /media

For a rough live view of changes, you can poll:

watch -n 2 findmnt

findmnt also has a built-in monitoring mode (--poll) that waits for mount table changes and prints them as they happen. Check findmnt --help on your system for exact behavior in your version.

Key Indicators to Review

What You See	Why It Matters	Suggested Action
/tmp, /var/tmp, or /dev/shm without noexec, nosuid, nodev	Writable staging areas run with fewer restrictions	Review against your hardening baseline; remount with restrictive options via fstab
Mount present in kernel table but absent from fstab	Manual or transient mount, possibly unauthorized	Identify who or what created it; check shell history and systemd units
Unfamiliar NFS or CIFS source	Possible shadow IT, misconfiguration, or data staging	Confirm with the owning team; review network logs for that host
Log partition near 100% usage	Logging may fail silently	Investigate cause; confirm log forwarding is intact
Unexpected read-write mount of sensitive data	Wider write access than needed	Apply least privilege; remount read-only where possible
Mount stacked over a directory that normally holds local files	Mounting over a path hides what was previously there	Compare against baseline; inspect with the mount removed in a controlled way

Detection and Prevention Techniques

Detection

• Baseline and diff. Capture findmnt --json output from known-good systems and compare on a schedule. Alert on new mounts, changed options, or new network sources.
• Use audit logging. Linux auditd can record mount-related system calls. Forward those events to your SIEM so mount activity is visible alongside process and login data.
• Correlate with process telemetry. A new mount followed by execution from that mount is a stronger signal than either event alone.

Prevention

• Harden by default. Put world-writable locations on their own mounts with nodev,nosuid,noexec where your applications allow it.
• Limit who can mount. Restrict privileged access and review sudo rules that permit mount operations.
• Manage configuration centrally. Enforce fstab through configuration management so drift is corrected rather than just discovered.
• Verify before reboot. Run findmnt --verify as part of change control for fstab edits.

No single control stops every attack. These measures reduce attack surface and make suspicious activity easier to spot, which is the realistic goal.

Expert Tips

• Use -T for investigations. When a file path shows up in an alert, findmnt -T /path/to/file tells you immediately which mount and which options apply to it.
• Pin your columns. Always specify -o in scripts. Default columns can vary between versions, and a script that depends on defaults will eventually break.
• Check column availability. Some columns, such as size-related ones, depend on your util-linux version. Test on your oldest supported distribution before rolling out a script fleet-wide.
• Read-only for forensics. When you attach evidence disks to an analysis workstation, confirm with findmnt -O ro that they are mounted read-only before touching them.
• Don't rely on one tool. findmnt shows what the kernel reports in your namespace. Pair it with process, network, and file integrity monitoring for a fuller picture.

Related Cybersecurity Topics You Should Explore

• Linux tune2fs Cheat Sheet: 41 Commands, 4 Costly Mistakes
  
• Linux blkid Command: 41 Examples Every SOC Analyst Should Know
  
• Linux fsck Command Guide: Fix Disk Errors Without Data Loss
  
• Linux mkfs Command Cheat Sheet: Format Disks Safely (2026)
  
• Linux parted Command Cheat Sheet: Partition Disks Safely
  
• Linux fdisk Command Cheat Sheet: Partition Disks Safely (2026)
  
• Linux lsblk Command: Cheat Sheet for Disks, USB & Encryption
  
• Linux umount Command Cheat Sheet: Safe Unmount Without Data Loss
  
• Linux Mount Commands Cheat Sheet: Secure Mounts (2026)

FAQ

What is the findmnt command used for?

It lists and searches mounted filesystems on Linux, showing source devices, mount points, filesystem types, and options. Admins use it for troubleshooting, and security teams use it for auditing and incident response.

What is the difference between findmnt and mount?

Both can show mounted filesystems, but findmnt offers a tree view, selectable columns, filtering, and structured output such as JSON. That makes it better suited to scripting and audits.

Why does findmnt return nothing for my directory?

A positional path matches only if it is a mount point, source, or tag. If the directory lives on a larger filesystem, use findmnt -T /your/path to find the containing mount.

How do I check if /tmp is mounted with noexec?

Run findmnt -T /tmp -o TARGET,OPTIONS and look for noexec in the OPTIONS column. If /tmp resolves to the root filesystem, it shares that filesystem's options.

Does noexec fully prevent malware execution?

No. It blocks direct execution of binaries from that mount, but interpreters can still run scripts that live there. Treat it as one layer among several controls.

How do I validate /etc/fstab safely?

Use findmnt --verify --verbose to check entries for common problems before rebooting. It reports issues but does not change your configuration.

Conclusion

findmnt is easy to overlook because it feels like an admin utility. In practice, it answers questions responders ask constantly: where does this file live, what restrictions apply to it, and did anything mount that shouldn't have? Build a baseline, check the options on your writable paths, compare fstab against reality, and capture snapshots in a structured format. Those few habits make mount-level anomalies much easier to catch, and they support audit and compliance work along the way.

Analysis based on SOC monitoring experience and review of the util-linux documentation.