🚨 Linux Error Guide: 'No such file or directory' when Searching — Fix find and locate

Overview

You know a file exists, but the tools that should find it come up empty or error out. With find, a bad starting path or an unquoted pattern is the usual culprit:

$ find /opt/aps -name app.conf
find: '/opt/aps': No such file or directory

With locate, the database is often just stale or missing:

$ locate app.conf
locate: can not open '/var/lib/mlocate/mlocate.db': No such file or directory

find searches the live filesystem in real time, so its failures are about the path you gave it and permissions. locate reads a prebuilt index (updatedb), so it can be fast but wrong — it will miss files created since the last index run and list files already deleted. Knowing which tool you’re using explains most “can’t find it” surprises.

Symptoms

• find <path> ... prints No such file or directory for the starting directory itself.
• find returns nothing for a file you can ls, or reports Permission denied on subtrees.
• locate <name> returns nothing for a file you just created.
• locate lists a path that no longer exists on disk.
• A pattern with * behaves unexpectedly because the shell expanded it before find saw it.

Common Root Causes

• Wrong or nonexistent start path — find errors immediately if the directory you told it to search doesn’t exist (typo, wrong mount).
• Stale locate database — updatedb hasn’t run since the file was created; the index is behind reality.
• Missing/uninitialized mlocate db — on minimal or fresh systems the database file doesn’t exist yet.
• Case sensitivity — -name App.conf won’t match app.conf; Linux filesystems are case-sensitive.
• Unquoted glob — the shell expands *.log before find, so find searches for the wrong literal name.
• Permission-hidden directories — find can’t descend into directories without execute permission, silently missing files.

Diagnostic Workflow

Confirm the start path exists before blaming find:

ls -ld /opt/aps                       # does the starting directory exist?
find / -type d -name aps 2>/dev/null  # locate the real directory name/path

Always quote the pattern so the shell doesn’t expand it, and use case-insensitive matching when unsure:

find /opt -name '*.conf'              # quoted: find handles the glob
find /opt -iname 'app.conf'           # -iname = case-insensitive

Separate real “not found” from permission-hidden results by discarding errors deliberately:

find / -name app.conf 2>/dev/null     # hide Permission denied noise
sudo find / -name app.conf            # search as root to see restricted dirs

For locate, refresh the index and verify it exists:

sudo updatedb                         # rebuild the mlocate/plocate database
locate -e app.conf                    # -e = only print files that still exist
locate --statistics                   # DB path, entry count, last build

Example Root Cause Analysis

A sysadmin swore a log file existed but find reported nothing:

$ find /var/log -name *.log
find: paths must precede expression: 'auth.log'

The shell had expanded *.log in the current directory before find ran, turning the command into find /var/log -name access.log auth.log .... Quoting the pattern fixed the parse, but it still returned nothing for a file owned by root under a 700 directory. Running as root revealed it:

$ find /var/log -iname '*.log' 2>/dev/null       # still missing one
$ sudo find /var/log -iname '*.log' | grep audit
/var/log/audit/audit.log                          # inside 700 audit dir

Two root causes stacked: an unquoted glob (shell expansion) and a 700 directory that the unprivileged user couldn’t traverse, so find skipped it. Quoting the pattern and searching with sufficient privileges surfaced the file. A parallel locate miss for a freshly created file was resolved simply by running sudo updatedb.

Prevention Best Practices

• Always quote find patterns ('*.log') so the shell doesn’t pre-expand them.
• Use -iname when case is uncertain, since Linux filenames are case-sensitive.
• Remember locate reflects the last updatedb; run updatedb after bulk file changes or use find for anything just created.
• Add 2>/dev/null to suppress permission noise, but search with sudo when results may live in restricted directories.
• Verify the start path exists (ls -ld) before deep find runs in scripts, and fail clearly if it doesn’t.
• Keep the mlocate/plocate cron or systemd timer enabled so the index stays reasonably fresh.

Quick Command Reference

ls -ld <startdir>                        # confirm find's start path exists
find <path> -iname '<pattern>'           # case-insensitive, quoted pattern
find / -name '<name>' 2>/dev/null        # suppress Permission denied noise
sudo find / -name '<name>'               # search restricted directories
sudo updatedb                            # rebuild locate database
locate -e <name>                         # only show files that still exist
locate --statistics                      # inspect the locate index

Conclusion

When a search “can’t find” a file that exists, first identify the tool. find works live, so check the start path, quote your glob, use -iname, and search with enough privilege to enter restricted directories. locate works from an index, so a fresh file or a stale entry just means updatedb needs to run — use locate -e to filter deleted paths. Matching the tool’s behavior to your expectation clears up nearly every “the file is right there” mystery.