Solved Attempting to run "sudo updatedb" for the locate command - getting a permission denied error.

[Priest_Apostate]

Just removed, rebooted, re-installed locate, rebooted. ran your apt remove command, and rebooted...no change to the /etc/ directory (in that the updatedb.conf command is still not there).

"su -" is also still being denied.

Belay that last response: I ran the "apt reinstall mlocate" command, and now see the file. Checking now, and adding the /run listing...

 

[f33dm3bits]

Just removed, rebooted, re-installed lcoate. ran your apt remove command, and rebooted...no change to the /etc/ directory (in that the updatedb.conf command is still not there).

Belay that last response: I ran the "apt reinstall mlocate" command, and now see the file. Checking now, and adding the /run listing...

I was about to say.

What happens when you run "sudo updatedb" now? What does your /etc/apt/sources.list file look like?

 

[Priest_Apostate]

Belay that last response: I ran the "apt reinstall mlocate" command, and now see the file. Checking now, and adding the /run listing...

Actually, it looks like adding that option (argument?) wasn't needed: the command completed.

 

[f33dm3bits]

Actually, it looks like adding that option (argument?) wasn't needed: the command completed.

You are able to run "sudo mlocate" now without it complaining about that filesystem?

 

[Priest_Apostate]

The original issue wasn't my inability to run "sudo mlocate." but to find out why the "updatedb" command was being denied when being run by sudo in order to update the "locate" package (I'm unsure as to why we keep getting sidetracked to "m/plocate"). My understanding about Linux (which I've been pretty open about it from the beginning as being very fledgling) is that there isn't any permission that is higher than sudo. As such, I had no idea why that command was being refused.

 

[f33dm3bits]

The original issue wasn't my inability to run "sudo mlocate." but to find out why the "updatedb" command was being denied when being run by sudo

That's what I meant, typo. Are you able to run "sudo updatedb" now without getting that filesystem error?

 

[Priest_Apostate]

That's what I meant, typo. Are you able to run "sudo updatedb" now without getting that filesystem error?

It is - thanks for the assistance on that! From what I gathered, the locate package didn't include that file - which doesn't make sense, if it is being tested on for the LPIC. I also noticed that the command worked without an issue when I tried it on my Rocky Linux install (in that mlocate didn't need to be installed there). So, I did learn some things about the Debian installation that weren't mentioned from my study documentation. I also learned about the UID and EUID - and how they differed when using sudo or logging in as root. I'm also researching on how to remove the rest of the GNOME components from my system.

Thanks for the assistance, all!

 

[f33dm3bits]

It is - thanks for the assistance on that! From what I gathered, the locate package didn't include that file

Great!

My understanding (which I've been pretty open about it being very fledgling) is that there isn't any permission that is higher than sudo. As such, I had no idea why that command was being refused.

Correct. So here's what happened. You installed "mlocate/plocate", normally that configuration file(/etc/updatedb.conf) is created automatically when you install that package. In your case for some reason that didn't happen(maybe a small bug that was triggered by something else?), but when you reinstalled "mlocate/plocate" it did create that file.

That file consists of the follow content.

PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs fuse.encfs fuse.glusterfs fuse.gocryptfs fuse.gvfsd-fuse fuse.mfs fuse.rclone fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs udev udf usbfs"

The import line being "PRUNEFS=", there you see several mentions of fuse which is what gvfs uses. So because that configuration file was missing and you ran "sudo updatedb" that the gvfs/fuse filesystem was not excluded and therefore giving you that permission denied each time.

I'm also researching on how to remove the rest of the GNOME components from my system.

Having run "apt remove gnome gnome-core should have removed it all. You can still run the following, that will probably remove all the Gnome dependencies if the previous command hasn't done that.

sudo apt autoremove

That should clean up anything you don't use but be sure to check for anything that you may still use or anything else important that it might remove. You can always reinstall a remove package though.

If that doesn't work you could still do this.

dpkg --list | grep -i gnome

Then remove all the packages that have gnome listed. Then afterwards you can run "sudo apt autoremove" again and check again if there is anything on the list to be removed that you use or is important.

if it is being tested on for the LPIC

Good luck on your LPIC exam!

Thanks for the assistance, all!

Glad you got it all sorted!

 

[Priest_Apostate]

Great!

Correct. So here's what happened. You installed "mlocate/plocate", normally that configuration file(/etc/updatedb.conf) is created automatically when you install that package. In your case for some reason that didn't happen(maybe a small bug that was triggered by something else?), but when you reinstalled "mlocate/plocate" it did create that file.

Where my understanding broke down was why did mlocate/plocate package need to be installed for the updatedb.conf to be added to the /etc directory, in order to have the locate package utilize the "updatedb" command: I never would have known that the mlocate package was needed for the locate package to work properly.

(Something like this was also the case in learning why the study guide's vi commands didn't work in Debian: by happenstance, my research found that Debian installed vim.tiny - which doesn't use the same commands. This, unfortunately, caused me to waste hours trying to find out what I did wrong with the commands. While I get that stuff like this is all part of the learning process, that wasted time was pretty frustrating!)

 

[osprey]

@f33dm3bits wrote:

If that doesn't work you could still do this.

dpkg --list | grep -i gnome

Then remove all the packages that have gnome listed. Then afterwards you can run "sudo apt autoremove" again and check again if there is anything on the list to be removed that you use or is important.

One needs to be very careful about anything with "gnome" in it's package name. The dpkg command above will likely show that there are many packages with "gnome" in their names, but even though the gnome desktop environment (DE) in not installed, a number of other desktop environments do depend on some gnome utilities or packages which have gnome in their name, and if these are removed, those other desktops will have their functions affected, some in seriously impaired ways.

When one looks at what depends on a small number of packages with "gnome" in their package names, taken as examples in the below explication, it is apparent that these "gnome"-looking packages are actually part of other desktops. For example, on a machine here running LXDE, (without any intention of running anything gnome) the following packages with "gnome" in their package name were installed by default:

gnome-accessibility-themes
gnome-brave-icon-theme
gnome-colors-common
gnome-colors
gnome-desktop3-data
gnome-disk-utility
gnome-dust-icon-theme
gnome-human-icon-theme
gnome-icon-theme
gnome-illustrious-icon-theme
gnome-keyring-pkcs11
gnome-keyring
gnome-noble-icon-theme
gnome-screenshot
gnome-system-tools
gnome-themes-extra-data
gnome-themes-extra
gnome-wine-icon-theme
gnome-wise-icon-theme
libgnome-desktop-3-20t64 her
libgnomecanvas2-0
libgnomecanvas2-common
libpam-gnome-keyring
pinentry-gnome3
policykit-1-gnome

Further, and more significantly, when one investigates what depends on some of these packages which have "gnome" in their name, without being part of a gnome desktop environment (DE), it becomes clear that other desktop environments also depend on them. For example, in the following outputs below it can be seen that:

mate-desktop-environment-extras depends on gnome-system-tools;
lxde (DE) depends on gnome-system-tools;
cinnamon (DE) depends on gnome-system-tools;
pmanfm (file manager) depends on gnome-system-tools;
budgie (DE) depends on libpam-gnome-keyring and libgnome-desktop-3-20t64;
cheese (webcam app) depends on libgnome-desktop-3-20t64;
etc.

The outputs that confirm these findings are as follows:

[ben@min ~/configs]$ apt-cache rdepends gnome-system-tools
gnome-system-tools
Reverse Depends:
  liboobs-1-5
  system-tools-backends-dev
  system-tools-backends
  system-tools-backends
  mate-desktop-environment-extras
  lxde


[ben@min ~/configs]$ apt-cache rdepends policykit-1-gnome
policykit-1-gnome
Reverse Depends:
  cinnamon
 |timekpr-next
 |thunar
 |riseup-vpn
  pcmanfm
 |network-manager-gnome
  libqapt3-runtime
 |gnome-system-tools
  cinnamon-control-center
  apper

[ben@min ~/configs]$ apt-cache rdepends libpam-gnome-keyring
libpam-gnome-keyring
Reverse Depends:
  gnome-core
  phosh-core
  budgie-desktop-environment                                     her
  gnome-screensaver
  gnome-keyring
  gnome-flashback
  gdm3
  cinnamon-screensaver

[ben@min ~/configs]$ apt-cache rdepends libgnome-desktop-3-20t64
libgnome-desktop-3-20t64
Reverse Depends:
<snip>
  budgie-session
  libevolution
  evince
  eog
  cheese
  budgie-core
  budgie-control-center

These dependencies indicate that one would benefit from being rather careful is removing packages simply because their package name includes "gnome". A more meticulous approach would be potentially less troublesome in the long run for the full functioning of the respective desktop environments that are not gnome, but which use packages from gnome which can be identified by having "gnome" in their package name.

For practical purposes, it may be more economical in some respects to leave gnome alone if it's already on the system, and simply install whatever else one wishes to use, and use that and ignore gnome.

 

[Priest_Apostate]

@f33dm3bits wrote:


One needs to be very careful about anything with "gnome" in it's package name. The dpkg command above will likely show that there are many packages with "gnome" in their names, but even though the gnome desktop environment (DE) in not installed, a number of other desktop environments do depend on some gnome utilities or packages which have gnome in their name, and if these are removed, those other desktops will have their functions affected, some in seriously impaired ways.

When one looks at what depends on a small number of packages with "gnome" in their package names, taken as examples in the below explication, it is apparent that these "gnome"-looking packages are actually part of other desktops. For example, on a machine here running LXDE, (without any intention of running anything gnome) the following packages with "gnome" in their package name were installed by default:

....

Further, and more significantly, when one investigates what depends on some of these packages which have "gnome" in their name, without being part of a gnome desktop environment (DE), it becomes clear that other desktop environments also depend on them. For example, in the following outputs below it can be seen that:

....

The outputs that confirm these findings are as follows:

[ben@min ~/configs]$ apt-cache rdepends gnome-system-tools
gnome-system-tools
Reverse Depends:
  liboobs-1-5
  system-tools-backends-dev
  system-tools-backends
  system-tools-backends
  mate-desktop-environment-extras
  lxde


[ben@min ~/configs]$ apt-cache rdepends policykit-1-gnome
policykit-1-gnome
Reverse Depends:
  cinnamon
 |timekpr-next
 |thunar
 |riseup-vpn
  pcmanfm
 |network-manager-gnome
  libqapt3-runtime
 |gnome-system-tools
  cinnamon-control-center
  apper

[ben@min ~/configs]$ apt-cache rdepends libpam-gnome-keyring
libpam-gnome-keyring
Reverse Depends:
  gnome-core
  phosh-core
  budgie-desktop-environment                                     her
  gnome-screensaver
  gnome-keyring
  gnome-flashback
  gdm3
  cinnamon-screensaver

[ben@min ~/configs]$ apt-cache rdepends libgnome-desktop-3-20t64
libgnome-desktop-3-20t64
Reverse Depends:
<snip>
  budgie-session
  libevolution
  evince
  eog
  cheese
  budgie-core
  budgie-control-center

These dependencies indicate that one would benefit from being rather careful is removing packages simply because their package name includes "gnome". A more meticulous approach would be potentially less troublesome in the long run for the full functioning of the respective desktop environments that are not gnome, but which use packages from gnome which can be identified by having "gnome" in their package name.

For practical purposes, it may be more economical in some respects to leave gnome alone if it's already on the system, and simply install whatever else one wishes to use, and use that and ignore gnome.

Kinda learned that the hard way, as "apt remove gnome gnome-core" and the other removal commands mentioned in this thread helped - but didn't remove the non-classic GNOME desktop environments.
Finally, I just tried sudo apt remove gnome *gnome, which seemed to do the trick - but I did have to reinstall Timeshift. Thanks for that "rdepends" command, as while I knew I needed a command to determine which packages relied upon which file, I didn't know what it was called.

The thing that keeps bugging me is that if the locate package didn't create the updatedb.conf file, and didn't recognize the command (which only worked when I installed the mlocate package, I'm thinking that while that resolved the updatedb command, that that command would only be useful for the mlocate package. While I understand the fact that the gvfs file wasn't listed in the PRUNEFS area, I didn't have to install that /run directive, in order to have the command work.

While I was given a light scolding for following directions, I can't help but wonder: how was I supposed to know that the locate command wouldn't utilize the updatedb.conf file - or that I needed an entirely different package in order to accomplish that?

Is that making sense? It seems to be (to me, at least) a case of "I don't know what I don't know."

 

[osprey]

The thing that keeps bugging me is that if the locate package didn't create the updatedb.conf file, and didn't recognize the command (which only worked when I installed the mlocate package, I'm thinking that while that resolved the updatedb command, that that command would only be useful for the mlocate package. While I understand the fact that the gvfs file wasn't listed in the PRUNEFS area, I didn't have to install that /run directive, in order to have the command work.

There are means of showing the files which packages install. In the case here with debian, the following would be useful to discover those files of interest and packages you mention:

[ben@min ~]$ apt-file show locate
locate: /etc/cron.daily/locate            
locate: /usr/bin/locate.findutils
locate: /usr/bin/updatedb.findutils
locate: /usr/lib/systemd/system/locate.service
locate: /usr/lib/systemd/system/locate.timer
locate: /usr/libexec/frcode
locate: /usr/share/doc/locate/README.Debian
locate: /usr/share/doc/locate/changelog.Debian.gz
locate: /usr/share/doc/locate/changelog.gz
locate: /usr/share/doc/locate/copyright
locate: /usr/share/lintian/overrides/locate
locate: /usr/share/man/man1/locate.findutils.1.gz
locate: /usr/share/man/man1/updatedb.findutils.1.gz
locate: /usr/share/man/man5/locatedb.5.gz

And:

[ben@min]$ apt-file show plocate
plocate: /etc/cron.daily/plocate          
plocate: /etc/updatedb.conf
plocate: /usr/bin/plocate
plocate: /usr/lib/systemd/system/plocate-updatedb.service
plocate: /usr/lib/systemd/system/plocate-updatedb.timer
plocate: /usr/sbin/plocate-build
plocate: /usr/sbin/updatedb.plocate
plocate: /usr/share/doc/plocate/changelog.Debian.gz
plocate: /usr/share/doc/plocate/copyright
plocate: /usr/share/man/man1/plocate.1.gz
plocate: /usr/share/man/man5/updatedb.conf.5.gz
plocate: /usr/share/man/man8/plocate-build.8.gz
plocate: /usr/share/man/man8/updatedb.plocate.8.gz
plocate: /var/lib/plocate/CACHEDIR.TAG

And, the absence of the package mlocate:

[ben@min]$ apt-file show mlocate
[ben@min]$

 

[wizardfromoz]

Just a heads up, folks. On

What package did you install to get this?

and

Just removed, rebooted, re-installed locate,

No, you likely reinstalled

mlocate

mlocate and plocate are either installed to, or available in the repositories of, all of the 90 or so Linux distros I run.

However the command at terminal, used is simply

locate <name_of_file>

Arch Wiki have this, in part

mlocate (Merging Locate) is a more secure version of the locate utility, that only shows files accessible to the user. plocate (Posting Locate) is a locate based on posting lists, consuming mlocate's database ahead-of-time and making a much faster (and smaller) index out of it.

If you have to install mlocate or plocate on your distro, and wish to use it in the same session, you must first run

sudo updatedb

before the command commencing

locate

will have success

Other than that, if you introduce new packages to your system run updatedb again in session.

In other circumstances, when you reboot your computer.

updatedb

will run automatically to update the database.

That would be the "locate" package: it was mentioned as one of the testing objectives in the LPIC-1 - but I found that it wasn't natively installed on my Debian system.

Yes it was, or should have been.

Both mlocate and plocate are in the Package List for your Debian 12 'Bookworm'.

The easiest way to locate updatedb.conf is to run

locate updatedb.conf

Mine in this LM 21.3 'Virginia' Cinnamon shows this

chris@VirginiaCinn-WD:~$ locate updatedb.conf
/etc/updatedb.conf
/usr/share/man/man5/updatedb.conf.5.gz

... and that location is the same for my Debian 12 'Bookworm' Cinnamon.

HTH

Wizard

 

[Priest_Apostate]

Just a heads up, folks. On



and



No, you likely reinstalled

mlocate

mlocate and plocate are either installed to, or available in the repositories of, all of the 90 or so Linux distros I run.

However the command at terminal, used is simply

locate <name_of_file>

...

Not trying to throw shade, but I only installed mlocate after locate failed to generate the file:
*************************************
priestapostate@XXXXXX:~$ apt search locate | grep locate/stable

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

dlocate/stable 1.12 all
locate/stable,now 4.9.0-4 amd64 [installed]
mlocate/stable,now 1.1.18-1 all [installed]
node-p-locate/stable 6.0.0-12 all
plocate/stable,now 1.1.18-1 amd64 [installed,automatic]


They show up as two separate packages when I perform an apt search:

*************************************
locate/stable,now 4.9.0-4 amd64 [installed]
maintain and query an index of a directory tree
*************************************

*************************************
priestapostate@XXXXXX:~$ apt search mlocate
Sorting... Done
Full Text Search... Done
mlocate/stable,now 1.1.18-1 all [installed]
transitional dummy package

plocate/stable,now 1.1.18-1 amd64 [installed,automatic]
much faster locate
*************************************

My point is (once again: not trying to be snarky, or throw shade) that I did manually install locate.

Arch Wiki have this, in part



If you have to install mlocate or plocate on your distro, and wish to use it in the same session, you must first run

sudo updatedb

before the command commencing

locate

will have success

Other than that, if you introduce new packages to your system run updatedb again in session.

In other circumstances, when you reboot your computer.

updatedb

will run automatically to update the database.

I can't answer to that.

Yes it was, or should have been.

Both mlocate and plocate are in the Package List for your Debian 12 'Bookworm'.

The easiest way to locate updatedb.conf is to run

locate updatedb.conf

Mine in this LM 21.3 'Virginia' Cinnamon shows this

chris@VirginiaCinn-WD:~$ locate updatedb.conf
/etc/updatedb.conf
/usr/share/man/man5/updatedb.conf.5.gz

... and that location is the same for my Debian 12 'Bookworm' Cinnamon.

Okay, this is where I have another point of confusion.
I didn't perform the locate command on the updatedb.conf, as I wouldn't have thought to do that for a few reasons:
1. If -- as mentioned in my studies, the locate command required the updatedb.conf file (that the system didn't detect) -- in order to properly run the updatedb command (which was failing to run), then wouldn't that have failed? I mean, I wouldn't have thought to place the updatedb.conf file in the /usr/share/man directory - so I would think that the system would have placed it there, and known to look for the file there - which it didn't.
2. If the locate command seemed to be malformed/corrupted/misconfigured in such a way as to not have the necessary updatedb.conf file, wouldn't it make sense to not use it as a tool?

 

[wizardfromoz]

My point is (once again: not trying to be snarky, or throw shade) that I did manually install locate.

That's OK

Can you now run

locate updatedb.conf

and provide the output please?

If it shows as being in /etc , can you look at the file in Dolphin, right-click it and choose Properties, and either list the content beside the date-time stamps (or screenshot the popup window), and also take a look in /etc/cron.daily/ and see if it has a script called plocate and report on its properties.

TIA

Wizard

 

[osprey]

@Priest_Apostate
As shown in post #52, in debian, the file updatedb.conf is part of the plocate package, and is not present in the locate package.

The locate package does not require the updatedb.conf file in order to run. There are machines here with only the locate package installed and they run the locate facility as expected. There is no "malformation" in the locate package.

The locate package is configured differently. One can inspect the file: /usr/bin/updatedb.findutils to get an idea of how it's configured.

As for the absence of the mlocate package shown in post #52, the machine in question is running debian trixie, for which there is no mlocate package available in the respective repositories. The package is only available in debian buster, bullseye and bookworm:

You have searched for packages that names contain mlocate in all suites, all sections, and all architectures. Found 1 matching packages.
Exact hits
Package mlocate

    buster (oldoldstable) (utils): quickly find files on the filesystem based on their name
    0.26-3: amd64 arm64 armhf i386
    bullseye (oldstable) (utils): quickly find files on the filesystem based on their name
    0.26-5: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
    bullseye-backports (utils): transitional dummy package
    1.1.13-1~bpo11+1: all
    bookworm (stable) (utils): transitional dummy package
    1.1.18-1: all

See: https://packages.debian.org

I realise this can all be rather confusing, and one's expectations may often clash with the realities. The most useful approach I think is to wade through documentation as one is doing a lot of trial and error on the machine. The two have to come together, and after time and increasing familiarity, they do ... most of the time

 

[Priest_Apostate]

That's OK

Can you now run

locate updatedb.conf

and provide the output please?

[priestapostate@XXXXXX ~]$ locate updatedb.conf
/etc/updatedb.conf
/usr/share/man/man5/updatedb.conf.5.gz
[priestapostate@XXXXXX ~]$

If it shows as being in /etc , can you look at the file in Dolphin, right-click it and choose Properties, and either list the content beside the date-time stamps (or screenshot the popup window),

and also take a look in /etc/cron.daily/ and see if it has a script called plocate and report on its properties.

TIA

Wizard

[priestapostate@XXXXXX ~]$ locate updatedb.conf
/etc/updatedb.conf
/usr/share/man/man5/updatedb.conf.5.gz
[priestapostate@XXXXXX ~]$ ^C
[priestapostate@XXXXXX ~]$ ls /etc/cron.daily
rkhunter
[priestapostate@XXXXXX ~]$ ls -a /etc/cron.daily
. .. rkhunter
[priestapostate@XXXXXX ~]$ sudo !!
sudo ls -a /etc/cron.daily
[sudo] password for priestapostate:
. .. rkhunter
[priestapostate@XXXXXX ~]$

 

[wizardfromoz]

the machine in question is running debian trixie,

Neofetch output in #2 page 1 shows Bookworm

 

[wizardfromoz]

Perhaps the OP can enlighten us.

 

[osprey]

Neofetch output in #2 page 1 shows Bookworm

Sorry about the ambiguity ... the "machine in question" I was referring to in post #56 was the one that is here on my network that failed to find the mlocate package. The point that was being made in post #52 was that there were helpful means for the OP to check on the files that he didn't seem to be able to find after expecting to find them. It was "bugging" him, but the information that could have resolved the issue was being shown post #52 for his benefit. The point of post #56 was to clarify where some confusion may have previously existed.