Using plocate to Find Files in an Inaccessible Filesystem

Use the plocate command to search for files within a mounted but inaccessible filesystem by leveraging its database-driven approach, which bypasses real-time directory traversal. Since plocate queries a pre-built index rather than scanning the live file tree, it can retrieve results even when the underlying filesystem is read-only, corrupted, or otherwise blocked from standard access methods.

Understanding Why Standard Search Fails

When a Linux filesystem becomes inaccessible, common commands like find, ls, or grep often fail with errors such as "Input/output error" or "Permission denied." This happens because these tools attempt to traverse the directory structure in real-time. They require direct, read-access permissions to open directories and list their contents. If the filesystem is mounted in a state where metadata cannot be read—perhaps due to corruption, a locked volume, or specific mount flags—these traditional tools hit a hard wall immediately. In contrast, plocate operates differently. It does not scan the disk at runtime. Instead, it queries a static database file (typically located at /var/lib/plocate/plocate.db) that was created during the last update of the locate database. This database contains a snapshot of all file paths indexed on the system. Because plocate reads only this database file, it does not need to interact with the potentially problematic filesystem directly during the search operation. As long as the database exists and includes entries for the inaccessible partition, plocate can return results without ever touching the broken mount point.

Prerequisites and Database Status

Before attempting to use plocate for this workaround, you must ensure that the locate database has been populated while the filesystem was still accessible. If the filesystem was never mounted or if the database has not been updated since the issue arose, plocate will have no data to query regarding those specific files. You can check the age of the database using the locate command with the -d flag or by checking the modification time of /var/lib/plocate/plocate.db. If the database is outdated, you may need to run sudo plocate -u to rebuild it, but this step requires the filesystem to be readable. Therefore, this method is primarily effective for finding files that were previously indexed. For new files added after the filesystem became inaccessible, this technique will not work unless you can temporarily restore read access to update the index. For related troubleshooting on storage issues, see Fixing External Storage Mounting Issues in Linux: A Guide to Using 'force' and 'fsck' Commands.

Executing the Search Command

The core advantage of plocate is its speed and low resource usage compared to older mlocate implementations. To search for a specific file or pattern within an inaccessible filesystem, simply run:

plocate filename_pattern

This command searches the entire database. If you know the file resides in a specific path prefix, you can filter the output using standard Unix tools. For example, to find files in a mounted but unreadable drive typically assigned to /mnt/broken_drive, you might pipe the output through grep:

plocate filename | grep /mnt/broken_drive

Note that plocate does not support complex regular expressions out of the box in the same way grep does; it uses simple globbing patterns. If you need advanced pattern matching, consider combining plocate with grep for post-processing, similar to how one might Find File Names with Grep Command for more complex text-based searches.

Handling Large Results and Performance

Because plocate searches the entire index, queries can return thousands of matches, especially if the pattern is generic. This can make the terminal sluggish or difficult to parse. To mitigate this, always use specific filenames or extensions. For instance, searching for .log will yield vastly different results than searching for config. If the database is extremely large, plocate remains significantly faster than find because it avoids I/O waits associated with reading directory structures. However, if the database itself is corrupted or too fragmented, you might encounter errors. In such cases, rebuilding the database is necessary, though this again requires temporary access to the filesystem. For scenarios involving monitoring changes or syncing data before a crash occurs, reviewing Sync Filesystem: Wait Done - Export Logs to USB Drive can provide insights into maintaining data integrity during unexpected failures.

Limitations and Risks

While plocate offers a clever workaround, it is not a repair tool. It cannot help you copy, move, or delete files from the inaccessible filesystem because those operations require actual filesystem interaction. It is purely a discovery mechanism based on historical data. Additionally, if the filesystem was formatted or heavily modified after the last database update, any information about those changes will be missing. Always verify critical file existence by restoring read-only access if possible, rather than relying solely on the index.

Frequently Asked Questions

Can plocate find files that were added after the filesystem became inaccessible?

No, plocate can only report on files that were present in the database at the time of the last update. If new files were created after the filesystem failed, they will not appear in the search results until the database is rebuilt with access restored.

Is plocate faster than find on a healthy system?

Yes, plocate is generally much faster than find because it queries a static database file instead of traversing the directory hierarchy. This makes it ideal for quick lookups, though it lacks the real-time accuracy of find.

What should I do if plocate returns no results for a known file?

First, check if the database is up to date by running sudo plocate -u. If the database is current and the file is still not found, it may have been deleted or moved outside the indexed paths, or the filesystem containing it was never included in the locate index configuration.

Can I use plocate to recover lost data?

No, plocate is a search utility, not a data recovery tool. It helps you identify the location of files based on existing records but cannot reconstruct deleted data or fix corrupted filesystem structures.

How do I exclude certain directories from plocate searches?

You can configure plocate to ignore specific directories by editing the /etc/updatedb.conf file. Adding paths to the PRUNEPATHS variable ensures those directories are excluded from future database updates, reducing noise in your search results.