Uniform locate paths across machines

Use case

Your personal files are on your *nix-based fileserver. Using a network filesystem, you mount the server shares on your personal computer, a Linux desktop. You want to be able to quickly find files on the server.

Actually, you also have a laptop and a few other PCs. On all those machines, you want instant search results for filename queries on the server. You only want to do indexing on your server because your other machines are often switched off and besides, indexing could be slow over the network and why should all those machines do redundant work?

Summary

Using mlocate, we run a cronjob on the server to do a regularupdatedb process. We make sure that the base directory path for both server and clients is the same, using bind mounts. The updatedb database file will be stored in a location that is accessible for the clients.

The clients will copy the database file. An environment variableLOCATE_PATH will be added on the clients using their .profile configuration file, so that the additional locate database file will be used.

On the client, you can use a regular locate command, or use frondends such as catfish or other tools, e.g. feeding the results in fzf.

On the Server

fstab

If the directory paths on your server differ from the mount paths on your clients, then you have to add bind mounts in /etc/fstab.

/data/share1  /mnt/share1  none  bind
/data/share2  /mnt/share2  none  bind
/data/share3  /mnt/share2  none  bind

updatedb script

Create a shellscript, e.g. updatedb_mounts.sh, which is responsible for the creation of database files. For each path or mountpoint, initially do e.g. touch /mnt/share1/mlocate.db and make sure it has the correct file permissions. Note that the directory paths of these mountpoints should be identical to the mountpoints on the clients.

#!/bin/sh
# create a mlocate database for a specific location
MOUNTS="/mnt/share1 /mnt/share2 /mnt/share3"
for MOUNT in $MOUNTS
do
    if ! [[ -f $MOUNT/mlocate.db ]]
    then
        echo "Couldn't updatedb $MOUNT, is it mounted?"
        exit 1
    fi
    updatedb -l 0 -o $MOUNT/mlocate.db -U $BASEDIR
done

Store this file in e.g. /usr/local/bin and make it executable usingchmod +x.

cron

Finally, we have to make sure this script is executed on a regular basis. You can do so by editing /etc/crontab, making a systemd timer, or whatever. If the shared files don’t change that often, a daily run will do:

ln -s /usr/local/bin/updatedb_mounts.sh /etc/cron.daily/updatedbmounts

On the Client

If your local network mountpoint differs from the server mountpoint, then follow the same bind mount trick as being explained for the server. For now, let’s assume the mountpoints have the same path.

You can use the mlocate database files from the server directly, although I would only recommend this for a Local Area Network (LAN).

.profile

Edit your ~/.profile settings and add a LOCATE_PATH environment variable. The full filepaths to the mlocate database files should be separated by a colon (:).

export LOCATE_PATH="/mnt/share1/mlocate.db:/mnt/share2/mlocate.db:/mnt/share3/mlocate.db"

Logoff, login again, and you’re set to go. Just use locate (r catfish or locate_and_select.sh (see below) or whatever tool you like to search for your files on the server.

local copy of database

Another approach for even faster search is to regularly copy the mlocate database files to a local directory and use that local copy in yourLOCATE_PATH environment variable. This is easy to implement; just a cronjob and a regular file copy operation suffice. Make sure your local copy doesn’t stay behind the version stored on the server.

Locate and Select

If you only want to use locate than the catfish utility can be slow. Feeding the results of locate to fzf or rofi and using the selection to automatically open a (GUI) file manager is another approach that can work very well. You might be interested in my own script, Locate and Select.

Deze blogpost werd in december 2022 overgezet van WordPress naar een methode gebaseerd op Markdown; het is mogelijk dat hierbij fouten of wijzigingen zijn ontstaan t.o.v. de originele blogpost.