Score:0

Permission Denied Grep

ru flag

I am completing a school assignment and it's pretty much based off of a murder case. I downloaded the custom files and I am currently searching for keywords within files. The question I am answering right now is: "Look for a file containing the text “apt. no.” to find that info".

I am fairly new to Linux and I am currently getting Permission Denied whenever I am entering the following command:

grep -inr apt.no

Any help on how to fix this would be greatly appreciated. The file I am looking for contains apt.no text in the file.

bbcharlieca@myvm:~$ grep -inr apt.no.
.viminfo:92:|2,1,1635317358,47,"apt.no"
.viminfo:92:|2,1,1635317355,47,"apt.no"
grep: nano.save: Permission denied
bbcharlieca@myvm:~$ 

enter image description here

Mark Kirby avatar
cn flag
You need to run the command as root `sudo grep -inr apt.no`
Lostinthesauce avatar
ru flag
How would I access the file now based off of the information I got?
Lostinthesauce avatar
ru flag
It went through fine but I'm confused as to how I this helps me find where the file or what the file's name is.
Mark Kirby avatar
cn flag
What exactly are you searching through, some custom files? The command for me returns a list of files, can you explain what exactly you are trying to achive?
st flag
@MarkKirby: Please, do *not* teach people to reflexively elevate privileges whenever they run into a problem. Instead, they should *understand* the problem and *fix* it. Clearly, the OP has encountered a file that they believe they should have access to but haven't. Teaching them to mindlessly *circumvent* access restrictions is dangerous. Rather, they should investigate what the problem is: are the access restrictions wrong? Or is maybe their belief that they *should have access* wrong? The two have *very* different solutions, and *neither* includes mindlessly re-running the program with sudo
Lostinthesauce avatar
ru flag
I am completing a school assignment and it's pretty much based off of a murder case. I downloaded the custom files and I am currently searching for keywords within files. The question I am answering right now is: **Look for a file containing the text “apt. no.” to find that info.**
Mark Kirby avatar
cn flag
@JörgWMittag I am not mindlessly suggesting it, it is a simple grep command, you are been way to cautious, it will cause no harm to the OP.
st flag
@MarkKirby: Are you convinced that the OP fully and completely understands what the command they are running does, what the error message they are receiving means, how and why, *exactly* the command they are running fails, how and why, *exactly* the command they are running is safe, and how and why, *exactly* the command you suggested them is safe? I, to be honest, am not. What you have essentially taught them is two things: 1) you can fix any problem by just slapping `sudo` in front of it, and 2) running code you don't understand suggested by a random guy on the Internet is perfectly fine.
st flag
The fundamental problem here is that the OP is trying to access a file that they expect to have access to, but don't. This can have many different root causes: the OP's expectation is wrong (they shouldn't have access, and the error is correct), the access restrictions are wrong (they *should* have access, and the permissions are wrong), they are not accessing the file they think they are accessing, and many other possibilities. All of these different problems have different possible solutions with different trade-offs. Without understanding which is the problem, it's not possible to solve it.
st flag
I have seen countless questions on [ubuntu.se], [unix.se], [su], [so], [apple.se], and others, where people suffered substantial economic or emotional loss by accidentally deleting or destroying data that was either economically or emotionally valuable, simply because they have been conditioned that they can fix any error they don't understand by slapping `sudo` in front of whatever they are trying to run. Which, indeed, usually *makes the error go away* but does nothing to actually *fix the problem*.
Score:5
fi flag

The -r flag to grep instructs it to search every file in your current directory and in all subdirectories. (You can find out about -r, -i-, and -n by reading the documentation, man grep.)

The command matched apt.no. in the file .viminfo, and printed the matching lines. Notice in your text you say you want to search for apt.no but in your screenshot (ugh; much better to copy and paste as text) you actually typed apt.no. with a trailing dot. Furthermore, your instructions seem to want you to search for apt. no. (with a space). Be aware that with grep, the dot is a wildcard character that will match any character, and if you're searching for text that contains a space it must* be placed inside quotes. Perhaps you meant to run this command, which looks for the literal string apt. no. without any wildcard matching?

grep -rF 'apt. no.'

Your grep also attempted to search the file nano.save, but this appears either not to be owned by you, or else you've removed your read permissions from it. If the file is under your own home directory you could probably safely remove this file (rm nano.save). If it's in a shared area you're either going to have to live with the error message, explicitly exclude it from grep, or tell the shell to discard all error messages from the command:

grep -Fr 'apt. no.'                          # Live with it
grep -Fr --exclude='nano.save' 'apt. no.'    # Exclude named file
grep -Fr 'apt. no.' 2>/dev/null              # Discard *all* error messages

If you have root permissions you could search with those permissions, but jumping up to root level should done with care; there are almost no restrictions whatsoever if you are running as root:

sudo grep -Fr 'apt. no.'                     # Run as root

* If not placed in quotes you need to escape every occurrence of a special character, such as a space. I'm not going to do that here.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.