I do in Posix find $HOME +perm 0666 -type f -exec grep -l "XSym" {} \; but get this which I do not understand

find: ‘/home/masi/.dbus’: Permission denied
grep: /home/masi/.viminfo: Permission denied
grep: /home/masi/.cache/dconf/user: Permission denied


drwx------  3 root root     4096 Jun 18 14:49 .dbus
-rw-------  1 root root     6266 Jun 18 13:24 .viminfo
-rw------- 1 root root 2 Jun 18 14:51 /home/masi/.cache/dconf/user

I do not like double negation structure and non-Posix things like ! -perm -g+r,u+r,o+r -prune here which I think is equivalent to ! -perm 0444 -prune.

Proposal after Kusalananda's fix

I do

# http://unix.stackexchange.com/a/121020/16920
find / -type d \! -perm 0666 -prune -o -type f -name '._*' -print

Output: no files. Expected output: many files with many appropriate files. I run

find / -type d \! -perm +0666 -prune -o -type f -name '._*' -print

I get

find: invalid mode ‘+0666’

System: Ubuntu 16.04 64 bit
Grep: 2.25
Find: 4.7.0-git

  • 2
    It's fine to prefer 0444 over u+r,g+r,o+r but in your command you didn't prune anything. There's no -prune in it. The pruning is what makes it skip the things you can't read. Also, +perm is definitely not right. It's always -perm. In some versions of find, -perm +0666 would be a valid predicate (though maybe not the one you want) – user41515 Jun 19 '16 at 21:42
  • 2
    Are you running the find as a nonroot user? They wouldn't have permission to read those ... – Jeff Schaller Jun 20 '16 at 2:54
  • to clear some things up: -perm +000 is deprected since 2005, that's why you get invalid mode ‘+0666’... use -perm /000 instead. – DJCrashdummy Nov 23 '19 at 22:11
  • and there are 3 different ways to search for permissions: -perm 000 (only lists absolutely exact matches), -perm -000 (list matches with at least all specified rights) and -perm /000 (lists matches with also only matching one of the specified rights). perhaps that's why you get no files as output by using -perm 0666. – DJCrashdummy Nov 23 '19 at 22:13

Those files and directories do not belong to you, they belong to the root user, and have too restrictive access permissions for find and grep to work. Therefore, find complains about not being able to enter the directory /home/masi/.dbus (to do its job), and grep complains about not being able to read the files (to do its job).

The files and directories do not belong to you, even though they are located in your home directory. The reason that they instead belong to the root user is likely that you have been running things (vim and other things) as root and whatever programs these were have created the files and directories.

You may change the ownership of these files and directories with chown masi:masi (masi:masi should be replaced with your username and your default group name, see your other files), but you need to be root to do it, so use sudo chown ....

If you want to make sure that all files and directories in your home directory belongs to you, do sudo chown -R masi:masi $HOME, but first be sure that this is really what you want.

EDIT: To find all files and directories in $HOME that doesn't belong to user masi, do this:

$ find $HOME \! -user masi
  • 2
    Well, did you run things as root? In any case, these are not overly important files, and may even be deleted if you wish. Cache files are always deletable, and I know for a fact that .viminfo only holds some state information from Vim, so that's deletable too. If I found a .dbus folder in my $HOME, I wouldn't care less if it was deleted. – Kusalananda Jun 20 '16 at 7:34
  • Please, see the body. I am having the original problem again and again. I really have to understand this case. I give another proposal but no output at all of the command. – Léo Léopold Hertz 준영 Jul 4 '16 at 15:54
  • @Masi Try again with -perm +0666. – Kusalananda Jul 6 '16 at 6:11
  • 1
    @Masi My answer was concerning why you get "permission denied" errors, because that was your question. I'm not sure what it is you want to do now. – Kusalananda Jul 7 '16 at 7:50
  • 1
    I want to run the command successfully. The original may be right but something causing permission denied. I think the problem is not necessarily with the parameter value. – Léo Léopold Hertz 준영 Jul 7 '16 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.