Jump to content

Even root can't update "updatedb"= forbiden


onederer

Recommended Posts

Greetings everyone:

 

I wrote a "locate" command to find something. It did find it, but complained that the data base is out of date for more than 8 days (older than 45 days). I tried what I could to update that database but even as root, it would not allow this to happen! Why? How do I update the database, when it won't enven let root to accomplish that?

 

It looks like the database points to the /run directory. I looked at the directory, and they were all belonging to root, and some applications has the permission for themselves. I found nothing out of the ordinary there.

 

root@Microknoppix:/# updatedb --output=onederer

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

 

 

Oh you gurus of the Linux world, kindly enlighten me!

 

Cheers!

Edited by onederer
Link to comment
Share on other sites

securitybreach

Leave off the carp at the end of that command. You're confusing it.

 

Just do this...

 

as root --> # updatedb

 

The reason being that the user onederer doesn't have access to /run/user/1000/gvfs

  • Like 1
Link to comment
Share on other sites

In the example above, the "carp" was an example of the miriad things that I tried. And yes I don't have access to the file that's shown on the example above. I am very aware of that fact. But no other options is offered when giving the command to update the database. The output that you see above is the result of "updatedb" as root. And the desired results are never completed after the command is executed. The database is never updated. I beileve that the "gvfs" has to do with Gnome, which I'm not using. I've got KDE. and the 1000, I assume that's the user's number or it could be in this case the root's number?

 

I looked in the Internet, and this problem now seems to be quite universal! The problem exists even in Apple OS's as well as many other Linux distros. I figured that you guys have already run into this and have a solution for this. Am I correct? I'm just not that aware of the underpinnings to deal with it any further. It's just that the updatedb, never updates anything, and just produces that error message that you've seen above. The command "locate" is also involved with this problem. The updatedb has a whole bunch of symlinks that it goes through, and no one has ever done anything to fix the problem.

 

The only soultion was that I saw a guy on my Internet search, who wrote his own script to overcome this problem, but I'm not sure that it would work in my situation, without breaking something. I would'nt even know where to store the script so that it would be usable every time..

 

Cheers!

Link to comment
Share on other sites

I guess that by now, you see what I'm up against. After all, this problem also creeped up into the Apple OS's. It seems to be pretty extensively spread all over the different OS's. What good is this if we can't update the DB with the new changes? Why has this been overlooked? I know that 'locate' works fine, but with old data, on a stale database. I would not be surprised if this also exists in the BSD Unixex. What do you think?

 

There is no 'SLOCATE' or 'MLOCATE" in my OS. It's just plain 'LOCATE'. At some point in the past ~45 days, updatedb once worked. And that was way before I started to use this OS. I have to assume that the OS's structure had been changed, and that broke the system for this particular command.

 

I still don't know how to fix it. Any takers?

 

Cheers!

Link to comment
Share on other sites

I did search on my system for Mlocate, and Slocate, and couldn't fine anything. Couldn't find any reference to it. I don't have any "M" tools in this machine. I did read the link that you sent me. From my understanding, I didn't find a clear way to fix this. Or at least, I probably fully didn't understand it. I saw more examples of how spread out this problem exists, and people trying to cope with it. Unfortunately, different versions of OS's have their own quirks, which makes it harder to narrow it to one point.

 

Cheers!

Link to comment
Share on other sites

V.T. Eric Layton

Honestly in 11 years, I have not seen an issue with slocate/mlocate running updatedb. Take a look at this thread: https://bbs.archlinu...c.php?id=147347

 

Same here, but 8 years.

 

===

 

Onederer, is this that same installation that you've been fighting with from this thread? http://forums.scotsnewsletter.com/index.php?showtopic=71943

 

If so, why are you killing yourself, man? You know this is a corrupted install. You could spend months trying to fix this. Is it the challenge? If so, cool. If you're just stubborn, well that's your biz, of course. Personally, I would NUKE the living do-do out of this installation and start from step 1 again.

  • Like 1
Link to comment
Share on other sites

Yes it is the same OS. I got the printer running, after making some changes. After a quick series of Os fiascos (4), in a very short time, I just couldn't see myself going through this again. I understand what you mean by the package slocate/mlocate. But I have to tell you, that in this os, a search for either one of these, doesn't come up with anything. but with a search for locate, and I get results galore. Why is it like this? I don't know. I didn't setup any of this. Mr. Knopper is the producer.

 

So I guess that I have to accept that there is no solution to this quirk. Updatedb is a dead elephant. And the OS still keeps on going without any database updates. And locate still finds what I ask of it, except when it comes to the database. I only wish I was a coder, but I'm not anymore. I only know ancient languages no longer in use. But if I only could code myself out of this, that would solve the problem. This OS is a good match for this net-book. It can run the pants out off WinXP on it's hard drive.

I'm still amazed that this OS is tightly packed into a 32GB memory USB stick, and has a lot of capabilities.

 

So, should we call this one terminated?

 

Cheers!

Link to comment
Share on other sites

V.T. Eric Layton

Well, you don't have to give it up for dead, Onederer. We'll still read about how you spend your time whipping yourself bloody while trying to get that installation to work. ;)

 

I think you'd really like Gentoo. :yes:

Link to comment
Share on other sites

Hey, Banbi!

 

Did you see the post I put up earlier, with the output, after calling "updatedb", as root, and the output that it gave me? It only went that far, and not further.

root@Microknoppix:/# updatedb --output=onederer

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

 

It was done using legal switches, no switches, whatever I tried to dream up to get rid of the "Permission denied", as root. It never went past that point. And I had no control that it would use the ?run/usr/1000/gvfs to execute my command. I don't understand what to do about it, and I'm giving up. I don't have the answers.

 

I appreciate the clue that you sent me, But that command is well and good for a system that's functioning as it should. In my case, you can see above, the results to"updatedb". I'm closing this post, because it's going nowhere. Many people on the WEB, have posted the same problem, I've seen no resolution for them also. It could be that there was some coding that was added to the OS, that broke other things in the process. I can't tell for sure. Anyway, we can't win them all.

 

Thank you all for your help. I really appreciate it.

 

Cheers!

Link to comment
Share on other sites

securitybreach

Why do you keep adding --output=onederer? I have been using locate for over a decade and have never seen that switch added. Just use plain ole updatedb as root without any other switch.

 

It should run for a second and return you to a prompt without any output.

Link to comment
Share on other sites

Just wondering: What was the result (output) of

 

# updatedb

 

???

-

updatedb

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

/usr/bin/find: `/run/user/1000/gvfs': Permission denied

Link to comment
Share on other sites

Mr. Security:

 

As I had posted before, that one time that you saw that switch, was only ONCE! I just happened to have taken a copy of that one time, and posted it here. I do not keep on doing this. This was just one of the many things that I tried to kill the "denied" problem. When nothing else worked, I had looked up different legal switches to see if that would make any difference. And it didn't. You know, when something doesn' work, try something else. When that didn't work, it was then that I came to this

WEB site, figuring that more people involved, may be able to find the key to eliminate that "denied" problem, as root. However, so far, that has not happened. So I've come the conclusion that since the OS is running fine, (minus the "updatedb" problem), I'll be able to live with it. The system can complain all it wants that the database is more than 8 days old. I'll just ignore it.

 

Cheers!

Link to comment
Share on other sites

securitybreach

Well what are the permissions on /run/user/1000/gvfs?

# ls -la /run/user/1000/gvfs

 

I do not have that file on Arch or Debian but it may clue us into why you do not have permission for that file.

 

Denied simply means that you do not have the correct permissions on the file or your user doesn't have the permissions.

Link to comment
Share on other sites

Well what are the permissions on /run/user/1000/gvfs?

# ls -la /run/user/1000/gvfs

 

I do not have that file on Arch or Debian but it may clue us into why you do not have permission for that file.

 

Denied simply means that you do not have the correct permissions on the file or your user doesn't have the permissions.

 

 

root@Microknoppix:/# ls -la /run/user/1000/gvfs

ls: cannot access /run/user/1000/gvfs: Permission denied

 

Precisely! This is what I was telling you! I've always used root to perform that task. As you can see from my copy and paste above, root has NO control for this function, and all that applies to it. And such as was stated in the topic of this post. It's just as if everything that's dealt with this one function (updatedb), is all wrapped up in an isolated cocoon, and is untoucheable.

That's part of the mystery. And I'm NOT always using switches (they didn't work anyway)! What is the value of 1000? What does it represent?? How does "gvfs" fit into the equasion? Evidently, that file is or was placed into the "/run" directory, which wound insinuate that this file may be something that is frequently run?? And to what results? What controls it??

 

These are all questions that have been spinning around in my head. :teehee: :'( What are your conclusions?

 

Cheers!

Link to comment
Share on other sites

securitybreach

Yup, your installation is toast... I see this sometimes on a usb drive, where you cannot read/write to it even as root. I end up having to use dd to wipe the drive. This tends to happen if I write the drive using dd=distro.iso of=/dev/drive

 

I hate to say it but.... point being, the installation is toast. Best to nuke and start over.

Link to comment
Share on other sites

I tried to dig deeper into gvfs. It seems to be a malformed directory, or possibly an encrypted directory which belongs to knoppix. It's impossible to delete the directory, no matter what. And that includes the parent directory. And yes I did as root. I tried to chown those directories. Imposible! So, I can't chown the directories, I can't delete them by force, I can't copy that directory to one that root owns, to inspect it. I even tried to move the directory to one of my own. NOGO! Is it possible to create such a directory and files like this on purpose? Here's a copy/paste of that section. That gvfs is iron-clad!

 

root@Microknoppix:/run/user/1000# ls -al

ls: cannot access gvfs: Permission denied

total 0

drwx------ 3 root root 60 Sep 16 01:54 .

drwxr-xr-x 6 root root 120 Sep 16 01:17 ..

d????????? ? ? ? ? ? gvfs;

 

 

One of the other numbers in that file is 1001, and that's my onederer:onederer number.

 

Cheers!

Link to comment
Share on other sites

securitybreach

I kinda' like "Mr. Breach," myself. ;)

 

I thought "Security" was your first name. ;)

 

It is but I like to use my pseudonym...

 

Odd... Since Knoppix is mainly used as a live cd, I would try another distro...

  • Like 1
Link to comment
Share on other sites

I tried to dig deeper into gvfs. It seems to be a malformed directory, or possibly an encrypted directory which belongs to knoppix.

 

Sorry, I don't have much to add. Since it's a Knoppix hard drive installation, I looked at two of my Debian Wheezy installations. Here, in Debian, there is no /run/user directory -- quite simply, there's no /user directory in the /run directory, in either installation.

 

In my Arch installation, I see a /run/user/1000 directory, but there's nothing named "gvfs" in there:

 

$ ls /run/user/1000
dconf pulse systemd

 

So, I don't know what that /run/user/1000/gvfs file in Knoppix is all about, except that I think I see some of the things that you've found during your research. Here's something related to all this: https://en.wikipedia.org/wiki/GVFS

 

It would be interesting to see if you get this figured out, so I am not necessarily suggesting that you get rid of the Knoppix installation. That being said, I have never quite seen the point of doing a Knoppix hard drive installation. My experiences with Knoppix live go back to at least Knoppix 3.7, which was released back in 2004. Knoppix was one of the first Linux distros I ran here, and I remembered from back then that it was supposed to be possible to do a Knoppix hard drive installation, even though Knoppix is mainly meant to be run live.

 

I like Knoppix; it's been useful here over the years. But, personally, in all this time I have never been able to come up with a good reason to attempt a Knoppix hard drive installation. Doing so is supposed to give you Debian, so my opinion has been (and remains) that it's better (and, easier) to just... install Debian.

  • Like 1
Link to comment
Share on other sites

HI.

 

I fiddled around the "gvfs" directory. Don't know what, but whatever I did, the "permission forbidden" saga is over! This morning, I did an updatedb command, and it did it, without complaining about the gvfs problem. Computer, heal thyself! Oh, I love that! To learn something, I spent a lot of time on this quirk.

 

As far as Knoppix is concerned, perhaps it's time for you guys to reconsider the posibilities of Knoppix. It is no longer just a "live" version. It can run live, as it's done for so many years past. But now, It can be installed into a standard hard drive, or a flash memory, with built-in persistance (totally self-contained and highly pocket portable). This is why I used a 32GB memory stick. Mr. Knopper is still trying to keep up with the times. What I have here, is a full-blown OS, with all the bells and whistles, stuffed into a tiny memory stick. In this case, the 32bit OS makes it's portability unversally usefull on any machine (with the exeption of my UEFI tablet YUCK!).

 

Cheers!

  • Like 2
Link to comment
Share on other sites

As far as Knoppix is concerned, perhaps it's time for you guys to reconsider the posibilities of Knoppix. It is no longer just a "live" version. It can run live, as it's done for so many years past. But now, It can be installed into a standard hard drive, or a flash memory, with built-in persistance (totally self-contained and highly pocket portable). This is why I used a 32GB memory stick. Mr. Knopper is still trying to keep up with the times. What I have here, is a full-blown OS, with all the bells and whistles, stuffed into a tiny memory stick. In this case, the 32bit OS makes it's portability unversally usefull on any machine (with the exeption of my UEFI tablet YUCK!).

 

Ah. For some reason, I thought you were working with a hard drive installation. A Knoppix "portable install" on a flash flash drive (with persistence) is nothing new, actually (see this). And you can certainly do something like that with other Debian-based distros (for example, I have the Debian-based MX-14 on a flash drive here, with persistence). So I can see how what you're doing could be useful. Is what you have something like this?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...