Ubuntu – 16.04 Locate not finding files in /mnt

16.04locatemount

I have a 16.04 installation set up with my Downloads folder pointing to a secondary hard drive (shows Downloads -> /mnt/data/Downloads ). When I run locate to search for files, it doesn't show any files on this drive. I've run a sudo updatedb and I check my updatedb.conf (nothing I see excluded the /mnt directory or the files I'm looking for)

The interesting thing to me is when I cd /mnt/data/Downloads then run locate I can see everything in this directory but not on my primary drive. It's almost like Ubuntu has two different locate databases depending on which drive I'm on.

How can I remedy this situation?

Additional: Here's my updatedb.conf

PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs ecryptfs fusesmb devtmpfs"

I tried running sudo locate and that didn't change the results. I tried running mlocate and sudo mlocate and that didn't change the results either.

I also tried finding another updatedb.conf file and came up empty.

Update 1: The file system on the secondary drive is ext4.

Update 2: Nothing's encrypted either. I've been Googling around and noticed that's been an issue for some users.

Update 3: I'm more confused now. I'm trying to find all of the .iso files on my machine, below are the results:

@:~$ locate FreeNAS

/mnt/data/Downloads/FreeNAS-9.3-RELEASE.iso

@:~$ locate *.iso

/home/hudsona/ubuntu-16.04.1-server-amd64.iso

@:~$ locate iso

/home//ubuntu-16.04.1-server-amd64.iso

/mnt/data/Downloads/FreeNAS-9.3-RELEASE.iso

(and a bunch of other results)

@:~$ find . -type f -name "*.iso"

./ubuntu-16.04.1-server-amd64.iso

Update 4: More results: sudo find / -type f -name "*.iso" gives me the results I want but takes a long time to come back with those results.

I wanted to dig in and see if I indeed did have two different databases since I get different locate results based on which drive I'm in. After checking the MAN page I searched for an mlocate.db file on my system, here's my results:

  • /usr/share/man/man5/mlocate.db.5.gz
  • /var/lib/mlocate/mlocate.db
  • /var/lib/mlocate/mlocate.db.VEzhqO

I was thinking possible the .VEzhqO file might be a secondary database so I tried specifying that with the -d flag for the locate command. That gave me "can not stat" error. The mystery continues.

Update 5: I have reproduced this on another Ubuntu machine, 16.04 server edition.

Update 6: So I have a solution, locate "*.iso" but now I'm curious "why" that works. I looked at the MAN page and these two links: http://www.linfo.org/locate.html and http://www.howtogeek.com/112674/how-to-find-files-and-folders-in-linux-using-the-command-line/ . None of these shed any light on why that works.

Best Answer

In all shells, using *.iso expands to a list of files before calling the command, so in

locate *.iso

the shell expands automatically the expression creating a filename list from files in the current directory. Suppose there where in the current directory two iso files file1.iso and file2.iso; the resulting command will actually be:

locate file1.iso file2.iso

then the shell will execute it. So, locate will try to find files containing these two strings, effectively searching for "*file1.iso*" or "*file2.iso*".

That's why locate iso find more files than locate *.iso; locate is actually searching for "*iso*" in the first case. The solution (and right way to use it, IMHO) is quoting the special chars of the shell when the command accepts expressions using them, like the following find command:

find /etc/ -type f -iname "*.conf"

If there where two or more conf files in the current directory and we don't use quotes, the find command will fail parsing the second filename generated, and our hair density will be severely reduced in desperation and googling ;D because the error message seems not related to the absence of quotes.

Related Question