Unable to use 'locate' to locate files mlocate.db permission denied

[Alin Claudiu Radut]

I'm using Hardy on a 1000h. When I'm trying to locate a file using locate I receive
$ locate gdm
locate: can not open `/var/lib/mlocate/mlocate.db': Permission denied

I listed /var/lib/locate and mlocate.db seems to be owned by root and group mlocate
$ ls -al /var/lib/mlocate
total 3204
drwxr-xr-x 2 root root 4096 2008-10-11 00:33 .
drwxr-xr-x 51 root root 4096 2008-10-06 21:01 ..
-rw-r----- 1 root mlocate 3266135 2008-10-11 00:33 mlocate.db

[Johan Frank (johan-frank)]

Probably the same issue as for crontab:
https://bugs.launchpad.net/ubuntu-eee/+bug/269265
... and for ping, reported here:
https://answers.launchpad.net/ubuntu-eee/+question/46970

So presumably the real question is why these don't have the same suid/sgid setting as in a vanilla ubuntu hardy install... I doubt it is an intentional change?

[Rettaw (rettaw)]

I have the same problem as the ones linked above along with the one reported. Using ubuntu eee 8.04
I don't know very precisely when the problem first arouse for ping and crontab, but locate was working with no problems up until I changed the hostname for my eee pc 901 which bugged sudo ( https://bugs.launchpad.net/ubuntu/+bug/203593 ).

Once I fixed sudo by going into the 127.0.1.1 entry in SYSTEM>ADMINISTRATION>NETWORK>(HOST TAB)) and changing it to the new hostname sudo started working again. But locate didn't and I even had to run updatedb to get sudo locate to return something at all...

Or that's how I perceived it anyway.

[Jesse (storyjesse)]

I have this problem with locate but not with ping or crontab.
I don't want to set set the s bit because locate is supposed to only show users the location of files they have permission to see.

The problem on my system seems to be that /var/lib/mlocate/mlocate.db is unreadable by others. If I chmod o+r then it works.
However after running updatedb as root the permissions are reset back to -rw-r-----
-rw-r----- 1 root mlocate 9204983 2008-11-20 20:15 /var/lib/mlocate/mlocate.db

I was wondering if there may be a reason for /var/lib/mlocate/mlocate.db to be unreadable by others because although it has a lot of binary bits (I presume that's what the highlighted "^@" are) there is also a lot of human readable text that could potentially be a security risk.

Does anyone know what this file's permissions are supposed to be? Say on an install where it has always worked?

[Ian Abbott (ian-abbott)]

Workaround:

sudo chgrp mlocate /usr/bin/mlocate
sudo chmod g+s /usr/bin/mlocate

[Jordan Callicoat (monkeesage)]

Better workaround (only have to apply it once):

sudo usermod -a -G mlocate $USER

Logout, log back in and locate works again.

[Fred Mora (launchpad-net-trace)]

Jordan,

I had the same problem. After a Jaunty install, I found that /usr/bin/mlocate belonged to the ssl-cert group, clearly incorrect!

Reading the man page for locate, I found that locate (which is symlinked to mlocate by default) must run as a set-gid mlocate (which means the process automatically belongs to the mlocate group on startup).

Ian Abbott's solution is therefore the "correct" one. Yours works, but users are not supposed to belong to this group. This might create security exposures on multi-user systems.

[Neal McBurnett (nealmcb)]

I still see this problem, running maverick. In my case the executable's group was avahi:

-rwxr-sr-x 1 root avahi 35432 2010-03-24 06:35 /usr/bin/mlocate

Ian's fix in comment #5 fixed it.

[Neal McBurnett (nealmcb)]

I still see this problem, running maverick. In my case the executable's group was avahi:

-rwxr-sr-x 1 root avahi 35432 2010-03-24 06:35 /usr/bin/mlocate

Ian's fix in comment 5 fixed it.

[Neal McBurnett (nealmcb)]

I still see this problem, running maverick. In my case the executable's group was avahi:

-rwxr-sr-x 1 root avahi 35432 2010-03-24 06:35 /usr/bin/mlocate

Ian's fix worked.

[Neal McBurnett (nealmcb)]

I still see this problem, running maverick. In my case the executable's group was avahi:

-rwxr-sr-x 1 root avahi 35432 2010-03-24 06:35 /usr/bin/mlocate

Ian's fix worked for me.

[Neal McBurnett (nealmcb)]

[Sorry for the spam - I didn't notice that my posts were working despite a popup saying "The following errors were encountered:
Object: , name: u'ubuntu-eee'"]

[J-K (johannes-out-of-the-forest)]

This bug is still present in Ubuntu 10.11!
Ian's fix in comment #5 fixed it.

[zasran (erik-zasran)]

Still there in Ubuntu 12.04

[zasran (erik-zasran)]

Still there in Ubuntu 12.04, is this going to be fixed eventually?

[Daniel (hackie)]

On a new Xubuntu 16.04 installation, I saw the following permissions:

ls -l /usr/bin/mlocate
-rwxr-xr-x 1 root saned 39520 Nov 18 2014 /usr/bin/mlocate

1) mlocate didn't have setuid (which might be ok for some use cases)
2) the group is saned which is completely wrong. I assume the group is assigned by gid instead of name. saned has gid=127 on my system

[bhaskar (bhaskar)]

Same issue on a 15.10 upgraded to 16.04:

e0101450@bhaskark:/Distrib/Ubuntu$ locate abc.def
locate: can not open `/var/lib/mlocate/mlocate.db': Permission denied
e0101450@bhaskark:/Distrib/Ubuntu$ ls -l /var/lib/mlocate/mlocate.db
-rw-r----- 1 root mlocate 25974609 May 16 09:21 /var/lib/mlocate/mlocate.db
e0101450@bhaskark:/Distrib/Ubuntu$ ls -ld /var/lib/mlocate/
drwxr-xr-x 2 root root 24 May 16 09:21 /var/lib/mlocate/
e0101450@bhaskark:/Distrib/Ubuntu$

[Andrey Bondarenko (abone)]

May be some some system groups change gid during system upgrade. In this case mlocate created before upgrade retains old gid and loses ability to read mlocate.db. I have access to several hosts and mlocate group have different gid there. Of course it does not explain what removes sgid.

Possible workaround is to reinstall mlocate package:

sudo aptitude resintall mlocate

[zasran (erik-zasran)]

Not sure what happened over time but I don't see the problem anymore, Ubuntu 20.10, mlocate 0.26-3ubuntu3