Finding files

Before you read. A colleague says the application reads its configuration from “a conf file somewhere under /etc or maybe /opt”. A monitoring alert says a filesystem is full and nobody knows what filled it. An auditor asks for every world-writable file on the machine.

Three questions, and none can be answered by knowing where to look, because that is precisely what is missing.

What would one command have to be able to do to answer all three?

Search by attribute rather than by location. Not “show me this file” but “show me every file that is a certain size, or a certain age, or has a certain permission”, starting anywhere and going all the way down.

That is find, and it is one of the two or three commands worth genuinely learning rather than looking up each time. It also has a -delete flag, which is why a good part of this lesson is about looking before acting.

Some words you will need

test

A condition applied to each file: -name, -size, -mtime. Several combine.

action

What happens to a match: print it, run a command, delete it. Printing is the default.

descend

To walk into a directory and everything below it. find does this by default; most commands do not.

index

A database of filenames built in advance, which locate searches instead of the disk.

What breaks without this

Disk-full incidents take an hour instead of a minute. “Which files are large and old” is one command, and without it you are clicking down through directories.

You cannot audit anything. Every hardening check (world-writable files, setuid binaries, files owned by a deleted account) is a find expression.

Cleanup jobs get written by hand and get it wrong. Deleting logs older than 30 days is a one-liner that is also one typo away from deleting everything.

The shape of the command

find WHERE  TESTS  ACTION
find /var/log  -name '*.log' -mtime +30  -delete

Read it left to right, because that is how it evaluates. Where to start, then conditions, then what to do. Conditions are ANDed by default, so more tests means fewer results.

By name, type, and size

The tree below is /srv/app, containing a logs directory with three .log files, plus conf and cache. The starting point given to find is ., the current directory.

# Debian 13 (trixie), x86_64
$ cd /srv/app; echo '--- by name ---'; find . -name '*.log'; echo '--- directories only ---'; find . -type d; echo '--- bigger than 100k ---'; find . -type f -size +100k
--- by name ---
./logs/app.log
./logs/big.log
./logs/archive.log
--- directories only ---
.
./logs
./conf
./cache
--- bigger than 100k ---
./logs/big.log

Four, because find tests the starting point too. . is itself a directory and it matches -type d, so it is printed like anything else. That is not a quirk; it follows from find walking the tree including its root, and it is why find . -type f -delete in the wrong directory is so destructive and why find /tmp -name '*' -exec rm -rf {} + tries to remove /tmp itself.

-mindepth 1 excludes the starting point when that matters.

Quote the pattern. find . -name '*.log' works; find . -name *.log lets the shell expand *.log first, against the current directory, and find receives something else entirely. If the current directory happens to hold exactly one .log file the command appears to work, which is worse than failing.

-iname is the case-insensitive version and worth reaching for by default on somebody else’s filesystem.

By age and permission

# Debian 13 (trixie), x86_64
$ cd /srv/app; echo '--- not touched in 30 days ---'; find . -type f -mtime +30; echo '--- world-writable, which is a finding ---'; find . -type f -perm -o+w; echo '--- and combining tests ---'; find . -type f -name '*.conf' -perm -o+w
--- not touched in 30 days ---
./logs/archive.log
--- world-writable, which is a finding ---
./conf/creds.conf
--- and combining tests ---
./conf/creds.conf

-mtime +30 means more than 30 days ago, -30 means within the last 30, and a bare 30 means exactly the 24-hour window 30 days back, which is almost never what anyone wants and is why some cleanup jobs have never deleted anything.

-mmin is the same in minutes, which is the one for “what changed during the incident”.

The -perm forms are not interchangeable:

The leading - is what you want nearly always: “has at least this bit”, whatever else is set.

Three expressions worth memorising, because they are standard audit checks:

sudo find / -perm -4000 -type f 2>/dev/null    # every setuid binary
sudo find / -type f -perm -o+w 2>/dev/null     # every world-writable file
sudo find / -nouser -o -nogroup 2>/dev/null    # owned by a deleted account

2>/dev/null because searching from / produces a permission error for every directory you cannot enter, and those drown the results.

find /var -path /var/lib/docker -prune -o -name '*.log' -print

find /var/log -type f -printf '%s\t%p\n' | sort -rn | head
find /home -type f -printf '%u %m %p\n'
find . -newermt '2026-08-01' -printf '%TY-%Tm-%Td %p\n'

Doing something with the matches

# Debian 13 (trixie), x86_64
$ cd /srv/app; echo '--- -exec runs a command per match ---'; find . -name '*.log' -exec ls -l {} +; echo '--- and file identifies by content, not by name ---'; file run.sh conf/app.conf logs/big.log
--- -exec runs a command per match ---
-rw-r--r--. 1 root root      9 Aug  8 03:19 ./logs/app.log
-rw-r--r--. 1 root root      4 Jun 29 03:19 ./logs/archive.log
-rw-r--r--. 1 root root 200000 Aug  8 03:19 ./logs/big.log
--- and file identifies by content, not by name ---
/bin/sh: 13: file: not found

{} is replaced by each match, and the terminator decides how:

Use + unless the command can only take one argument at a time. On ten thousand files that is one process against ten thousand.

That last line is a real capture and a real lesson from topic 05 arriving again: file is not installed on a minimal Debian image. With it present:

# Debian 13 (trixie), x86_64
$ cd /srv/app; file run.sh app.conf mystery
run.sh:   POSIX shell script, ASCII text executable
app.conf: ASCII text
mystery:  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0243f2a3ad64d635299a574bbc8ef951ddde9b21, for GNU/Linux 3.2.0, stripped

file reads the contents, not the name. mystery has no extension and is correctly identified as a 64-bit executable, with its architecture and whether it was stripped. On Linux an extension is a human convention that nothing enforces, so file is how you find out what something actually is, and a file called notes.txt that reports gzip compressed data is a common and useful discovery.

stat is the companion for metadata. stat -c '%s %U %a %y %n' file gives size, owner, mode, modification time, and name on one line: ls -l with fields you chose.

find /var/log -name '*.log' -mtime +30            # look
find /var/log -name '*.log' -mtime +30 -delete    # then act

locate, and why it lies

locate searches a pre-built index rather than the disk, which makes it essentially instant across a whole filesystem where find / takes minutes.

locate nginx.conf
sudo updatedb        # rebuild the index

The index is rebuilt on a schedule, typically daily by a systemd timer. So a file created this morning is not in it, a file deleted this morning still is, and anything under a directory excluded by /etc/updatedb.conf never appears.

That makes locate excellent for “where does this distribution keep that program” and unsuitable for anything about the current state of the machine. find reads the actual filesystem and is never stale.

Three narrower tools, none of which is a general search:

find / -path /proc -prune -o -name '*.conf' -print

find /var -type f -printf '%s %p\n' | sort -rn | head -20

Across distributions

plocate has replaced mlocate on both families and is much faster. Neither is installed by default on a minimal server, which is one more reason find is the one to know properly.

Prove it

Before any destructive find:

# 1. What does it match, with no action at all
find /var/log -name '*.log' -mtime +30

# 2. Count it, so a surprising number is obvious
find /var/log -name '*.log' -mtime +30 | wc -l

# 3. Sizes and dates, so you know what you are losing
find /var/log -name '*.log' -mtime +30 -printf '%TY-%Tm-%Td %10s %p\n' | sort

# 4. Only now add the action
find /var/log -name '*.log' -mtime +30 -delete

Step 2 is the one that catches the mistake. A cleanup expected to remove forty files that reports 40,000 has something wrong with it, and the count takes no longer than the deletion would have.

What trips people up

1. Forgetting to quote the pattern

find . -name *.log is expanded by the shell first. With one matching file in the current directory it appears to work; with several it is a syntax error.

Quote it: -name '*.log'.

2. locate is out of date

It searches an index rebuilt daily. New files are missing, deleted files are still listed, excluded directories never appear.

sudo updatedb refreshes it. Use find for anything about the current state.

3. -exec with a semicolon on a large tree

\; forks once per file. On a large tree that is minutes rather than seconds.

+ batches. Use it unless the command genuinely takes one argument at a time.

4. Searching from / without -xdev

Descends into /proc, /sys, container overlays, and NFS mounts, where an unresponsive server hangs the command indefinitely.

-xdev stays on one filesystem; 2>/dev/null suppresses the permission noise.

5. -mtime 30 when you meant +30

A bare number is exactly that day. A cleanup job that has never deleted anything is usually a missing +.

Work it through

A monitoring alert says /var is at 96%. The server is live.

Reason through the order before reading on.

Confirm it is space and not inodes. df -h /var and df -i /var. If inodes are exhausted and blocks are not, you are looking for millions of tiny files rather than a few large ones, and the search is a different one.

Find the weight, not the files. Directories before files:

du -h --max-depth=1 /var 2>/dev/null | sort -h | tail

which names the branch, then descend one level at a time. du is the right tool here because it aggregates, and the answer to “what is using the space” is usually a directory rather than any single file.

Once you have the branch, ask find for specifics:

find /var/log -type f -printf '%s %TY-%Tm-%Td %p\n' | sort -rn | head -20

Twenty largest files with dates, one pass, no forking. The dates matter as much as the sizes: they tell you whether this is slow accumulation or something that started on Tuesday.

Fourth (the step people skip), check for deleted-but-open files:

sudo lsof +L1

Straight from the last lesson. If du totals far less than df reports used, the difference is a file somebody already deleted that a process still holds open. No search will find it by name, because it has none.

Only then clean up, with the look-first sequence from Prove it.

Now the point worth extracting. du and find answer different questions and the order matters. du tells you where the space went by aggregating upward; find tells you which files, once you know where to look. Starting with find / gives you a list too long to read and takes a long time producing it.

And the habit: the count before the deletion, every time. It costs nothing, it runs the exact expression you are about to act on, and a number that surprises you is the only warning you are going to get.

Try it

Optional, on any machine.

1. find /etc -name '*.conf' | head, then try it without the quotes.
2. find /var/log -type f -size +1M 2>/dev/null.
3. find /etc -type f -mtime -7 2>/dev/null, what changed this week.
4. sudo find /usr -perm -4000 -type f and read the setuid list.
5. find /var -type f -printf '%s %p\n' 2>/dev/null | sort -rn | head -10.
6. file on a few things in /usr/bin and on a config file.
7. stat /etc/passwd and find all three timestamps.

Verification step. You have it when you can write, without looking anything up, an expression that finds every file over 100 MB not modified in six months under a given directory, and show the list before deleting any of it.

Check yourself

References

• find(1) - Linux man-pages project. Accessed 2026-08-07.
• xargs(1) - Linux man-pages project. Accessed 2026-08-07.
• stat(1) - Linux man-pages project. Accessed 2026-08-07.
• file(1) - Linux man-pages project. Accessed 2026-08-07.
• locate(1) - Debian Project. Accessed 2026-08-07.
• GNU Findutils manual - GNU Project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on a Debian 13 (trixie) container. Blocks without one are illustrative.