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, 2016 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, 2016 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. Nov 23, 2019 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. Nov 23, 2019 at 22:13

1 Answer 1


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, 2016 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. Jul 4, 2016 at 15:54
  • @Masi Try again with -perm +0666.
    – Kusalananda
    Jul 6, 2016 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, 2016 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. Jul 7, 2016 at 13:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .