I selected /home/ to be encrypted when I was installing Ubuntu. Now, is it possible to make locate work with an encrypted partition like this?

  • I have the same problem - locate will find files outside of my encrypted home partition but cannot see them inside it. (To be honest, I wish I'd never encrypted it when I installed Ubuntu in the first place, with all the problems I've had with it!) Please can someone explain in clear steps what I need to do to be able to make locate be able to index data on an encrypted home partition. I'm a relative newbie so it's not obvious what to do from reading the above:).
    – user11061
    Commented Feb 19, 2011 at 14:40
  • 5
    Your /home is a virtual file system (ecryptfs). It is "mounted" as an accessible partition when you log in. Check your /etc/updatedb.conf and a) remove ecryptfs from ignored file systems (PRUNEFS) b) change to PRUNE_BIND_MOUNTS="no"
    – m33lky
    Commented Feb 26, 2011 at 3:56
  • 4
    After that you can run sudo updatedb to index new files.
    – m33lky
    Commented Feb 26, 2011 at 4:03
  • 1
    keep in mind that the database locate uses lives in unencrypted space, possibly compromising your encryption by disclosing filenames Commented Feb 27, 2011 at 12:59

3 Answers 3


I both "run locate (updatedb) when I'm logged in", as mentioned above, and I keep my part of the locate database under my encrypted $HOME.

export LOCATE_PATH="$HOME/var/mlocate.db"

and then I index the files in$HOME with

updatedb -l 0 -o $HOME/var/mlocate.db -U $HOME

Now I have a complete index of $HOME but the database isn't visible unless $HOME is mounted and decrypted.

  • That's a nice solution. How did you migrate your db there?
    – m33lky
    Commented Jan 8, 2012 at 23:51
  • 4
    I didn't. I just generated a db for my (encrypted) home tree, with updatedb -l 0 -o $HOME/var/mlocate.db $HOME. man locate says it will search the default database (/var/lib/mlocate/mlocate.db), then the list of databases in $LOCATE_PATH.
    – waltinator
    Commented Jan 9, 2012 at 6:46
  • 3
    Don't "remove ecryptfs from the PRUNEFS definition in /etc/updatedb.conf. When you're logged in, /home/$USER is decrypted, but the encrypted files and filenames in /home/$USER/.Private should be ignored. When your $HOME is not mounted, others won't have access to the db or the (unencrypted) files of filenames.
    – waltinator
    Commented Jan 9, 2012 at 7:13
  • 2
    updatedb -l 0 -o $HOME/var/mlocate.db $HOME there is missing -U it should be updatedb -l 0 -o $HOME/var/mlocate.db -U $HOME
    – destan
    Commented Mar 22, 2012 at 12:17
  • 2
    My bad, @destin I've extended my method to index removeable media, too, using Steve Collyer's bash_path_funcs ( linuxjournal.com/article/3645 ). With the removeable medium mounted (as /media/_name_) I do updatedb -l 0 -o ~/var/mlocate/_name_.db -U /media/_name_ In my .bashrc, I have export LOCATE_PATH="$HOME/var/mlocate/mlocate.db for i in $HOME/var/mlocate/*.db ; do addpath -p LOCATE_PATH $i done uniqpath -p LOCATE_PATH and locate can show me filenames even when the medium is NOT mounted.
    – waltinator
    Commented Mar 23, 2012 at 4:42

How about running updatedb when your file system is decrypted and try to match environment variables to read/write it?

After reading the man page, add two variables to your BASH RC file.

man locate
echo "export LOCATE_PATH=$HOME/var/lib/mlocate/mlocate.db:$LOCATE_PATH" >> ~/.bashrc
echo "export DBPATH=$HOME/var/lib/mlocate/mlocate.db:$DBPATH" >> ~/.bashrc

Make the directory specified above and add $username to the mlocate group.

mkdir -p ~/var/lib/mlocate/
sudo usermod -a -G mlocate $username

Log out and in again to count your user in the mlocate group and get the new environment variables. Now when you run,

updatedb -o $LOCATE_PATH

are the decrypted files in a locate database now? Or, what did you do to make it work or better?

You may also want to add updatedb to user's crontab. First run:

crontab -e

And add the following line:

0 12 * * * updatedb -o $HOME/var/locate
  • See my comment to Martin. I'm trying to understand if there are any security considerations or proper configuration was just overlooked by Ubuntu.
    – m33lky
    Commented Jan 10, 2011 at 0:23
  • Because of ecryptfs being listed in the PRUNEFS variable at /etc/updatedb.conf, you probably also need to use --prunefs "nfs" . This seems to be a good solution because it stores and updates the a per user index from the user profile. Commented Jan 10, 2011 at 23:40
  • @m33lky The issue is this: you have asked to encrypt your homedir, so nobody (not even root!) can read it without the password. The smart solution is a per-user locate database. The easy solution for a single-user machine is to remove ecryptfs and scan when you are logged in. In the future, perhaps locate could aggregate results from the global DB and the current user's home DB. Commented Jun 22, 2013 at 12:29

It's not really possible to update the database index without being logged in. You should log in and run the updatedb command.

Check your config in /etc/updatedb.conf. Remove ecryptfs from PRUNEFS and probably /home/.ecryptfs from PRUNEPATHS. Don't forget to run sudo updatedb after.

  • 1
    updatedb.conf prunes ecryptfs. Also, PRUNE_BIND_MOUNTS="yes". I'm trying to understand the reasoning behind such defaults as this is not user-friendly to have results from /home missing in your searches :)
    – m33lky
    Commented Jan 10, 2011 at 0:21
  • I'm guessing the functionality for home is to have a per user indexer... but that's speculation. Commented Jan 10, 2011 at 4:31
  • Without encryption /home gets indexed, so I expect the same behavior...
    – m33lky
    Commented Jan 10, 2011 at 4:34
  • 1
    I was describing the situation from the user interface perspective.
    – m33lky
    Commented Jan 12, 2011 at 6:54
  • 2
    If you encrypted the entire disk, this wouldn't be an issue, if you only had a home encryption then you now need to start indexing per user and using each individual encryption... in fact you might as well just stash the home index in the user's home folder.... all of which is major development and cost for something most users never see. Please report the bug against the locate database tools project. Commented Jan 12, 2011 at 7:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .