updatedb - incorrect permissions on /var/lib/mlocate after zypper dup


If you try to run

sudo updatedb you get the following response:

updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

Looking at the folder it’s owned by nobody root (or the other way round)

There is a temporary fix - until the next reboot where it gets reset

sudo chown root: /var/lib/mlocate

I think this happened at the DUP to 20180613

As I say, I have a workaround - haven’t really looked at fixing it

i see that /etc/sysconfig/locate has


Does that change the ownership of the folder?

I note the timestamp on that file is approx the time I was running a zypper dup by the way…


I see the same thing. I don’t chown it, but run

sudo -u nobody updatedb

It has been reported on the mailing lists and in bugzilla.

Ah, OK.

That’s two workarounds.

I note that changing the line in




persists the folder ownership as root:root over a reboot

However, I wonder if there was a specific reason for having it owned by nobody:root?

No idea, it’s even nobody:nobody.

Yes, probably.

I expect that it is so that it only looks at files that are readable by everyone. You really would not want it adding user passwords (and similar) into its database.

Updatedb runs as “nobody:nobody” for similar reasons to apache2 running as “wwwrun:wwwrun” etc. It is intended to enable an unprivileged process to access the data files without the risk of privilege escalation via suid tactics.

There is a daily cron job that runs updatedb as nobody. The time of day is set in sysconfig – the default is 15 minutes after the last boot.

The updatedb database is an index of file-paths, not file contents. Therfore non-admins do not have read or write access to /etc/shadow, etc.