Linux find permission denied exclude

Linux / Unix Find Command Avoid Permission Denied Messages

W hen I type find . -type d -name «foo» command I get Permission denied error messages. How do I exclude all “permission denied: messages from the find command under Linux or Unix like operating systems?

The find command is used to locate files on a Linux or Unix like operating system. The find command will search directory to match the supplied search criteria. You can search for files by

Tutorial details
Difficulty level	Easy
Root privileges	No
Requirements	find command+ Unix like os
Est. reading time	2m

type, name, owner, group, date, permissions and more. By default the find will search all subdirectories for you. Let us see how to hide and fix permission denied message when using the find on Linux or Unix-like system.

Find command basic syntax

The syntax is as follows:
find where-to-look criteria action
find /dir/to/search -name filetosearch
find /dir/to/search -name «*.c»
find /home/nixcraft/project/ -name «*.py» -print
In this example, find will search the /tmp directory for any files named “data*.txt” and display their pathnames:

Fig. 01: Find will show an error message for each directory on which you don’t have read permission.

How to hide or fix find command permission denied messages

In this above example, I do not have read permission for vmware-root and orbit-Debian-gdm directories. To to avoid this problem try the following syntax:

Sample outputs without permission denied spam from find command:

How does it works?

The 2>/dev/null at the end of the find command tells your shell to redirect the error messages (FD #2) to /dev/null, so you don’t have to see them on screen. Use /dev/null to to send any unwanted output from program/command. All data written on a /dev/null special file is discarded by the system. To redirect standard error to /dev/null and store file list to output.txt, type:

Exclude all “permission denied” messages from “find” command on Linux

There is one problem with the following command. It would filter out all error messages created by find command, not just the permission denied ones:

To avoid that try the following find command along with grep command on Linux or Unix-like systems:

In short you should use following syntax to skip “permission denied” errors messages when running find in Linux or Unix-based systems:

To store output to a file run:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Conclusion

You learned how to hide and fix permission denied messages when using the find command on your Linux, Unix, or macOS-based systems. Of course, we can also run the command as sudo when possible but avoid all this mess. Unfortunately, you will not get sudo or root access at all times. Hence, we talked about various methods here. For your ready references, sudo syntax would be as follows:
sudo find /dir/to/search -name «pattern» -action
sudo find / -name «jail.conf» -print
Please see find/bash command man page online or read it by typing the following man command:
man find
man bash
man zsh
man ksh

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Category	List of Unix and Linux commands
Documentation	help • mandb • man • pinfo
Disk space analyzers	df • duf • ncdu • pydf
File Management	cat • cp • less • mkdir • more • tree
Firewall	Alpine Awall • CentOS 8 • OpenSUSE • RHEL 8 • Ubuntu 16.04 • Ubuntu 18.04 • Ubuntu 20.04
Linux Desktop Apps	Skype • Spotify • VLC 3
Modern utilities	bat • exa
Network Utilities	NetHogs • dig • host • ip • nmap
OpenVPN	CentOS 7 • CentOS 8 • Debian 10 • Debian 8/9 • Ubuntu 18.04 • Ubuntu 20.04
Package Manager	apk • apt
Processes Management	bg • chroot • cron • disown • fg • glances • gtop • jobs • killall • kill • pidof • pstree • pwdx • time • vtop
Searching	ag • grep • whereis • which
Shell builtins	compgen • echo • printf
Text processing	cut • rev
User Information	groups • id • lastcomm • last • lid/libuser-lid • logname • members • users • whoami • who • w
WireGuard VPN	Alpine • CentOS 8 • Debian 10 • Firewall • Ubuntu 20.04

Comments on this entry are closed.

Both errors and warning are thrown into stderr is there any way we can identify that the command has a warning in it and not the error ??
Apart from checking the return code !!

Just use sudo (assuming you’re not running it in a script)

Источник

How can I exclude all “permission denied” result lines from “grep”?

So, the thing is, I’m on linux terminal using grep command and I want the output without all the lines where it prints at the beginning «grep:» or the lines that begins with «./», because now I’m getting something like this:

I have tried this:

I have also tried this one:

And finally this one:

But I keep getting same results as if I haven’t put anything after the |, any ideas? What am I missing?

2 Answers 2

The messages you are receiving is due to a lack of permission on those files, i.e., those are error messages.
All you have to do is to redirect the stderr (standard error output) to /dev/null , like this:

To lear more about redirection (on bash), read this article: Bash Reference Manual — Redirections

Edit: You can also just suppress error messages by using:

I prefer to use the -s ‘suppress’ flag:

Note the «Portability note» from the grep man page:

Suppress error messages about nonexistent or unreadable files. Portability note: unlike GNU grep, 7th Edition Unix grep did not conform to POSIX, because it lacked -q and its -s option behaved like GNU grep’s -q option. USG-style grep also lacked -q but its -s option behaved like GNU grep. Portable shell scripts should avoid both -q and -s and should redirect standard and error output to /dev/null instead. (-s is specified by POSIX.)

Источник

How do I remove «permission denied» printout statements from the find program?

3 Answers 3

Those messages are sent to stderr, and pretty much only those messages are generally seen on that output stream. You can close it or redirect it on the command-line.

Also, if you are going to search the root directory (/), then it is often good to nice the process so find doesn’t consume all the resources.

This decreases the priority of the process allowing other processes more time on the CPU. Of course if nothing else is using the CPU, it doesn’t do anything. 🙂 To be technical, the NI value (seen from ps -l ) increase the PRI value. Lower PRI values have a higher priority. Compare ps -l with nice ps -l .

I would just like point out this answer by @Gilles in Exclude paths that make find complain about permissions — Unix & Linux Stack Exchange; it basically involves a construct for find that makes it not descend unreadable directories, and in that sense, is probably also a bit faster.

This would seem to work for me:

With GNU find or any other find that supports the -readable and -executable predicates:

For some reason, I need to add all of the g+r,u+r,o+r (shortcut for that is a+r ), otherwise if one of them is left out, I may still get «Permission Denied» hits.

Here is a breakdown of how I see this (note the -a (and) operator in find is implicit between two predicates):

Note that without the last -print , I get some extra items shown (that have nothing to do with -name ‘netcdf’ ); the -print ensures that only the name matches are printed (if any).

Источник

How can I exclude all «permission denied» messages from «find»?

I need to hide all permission denied messages from:

I am experimenting when such message arises. I need to gather all folders and files, to which it does not arise.

Is it possible to direct the permission levels to the files_and_folders file?

How can I hide the errors at the same time?

20 Answers 20

This hides not just the Permission denied errors, of course, but all error messages.

If you really want to keep other possible errors, such as too many hops on a symlink, but not the permission denied ones, then you’d probably have to take a flying guess that you don’t have many files called ‘permission denied’ and try:

If you strictly want to filter just standard error, you can use the more elaborate construction:

The I/O redirection on the find command is: 2>&1 > files_and_folders | . The pipe redirects standard output to the grep command and is applied first. The 2>&1 sends standard error to the same place as standard output (the pipe). The > files_and_folders sends standard output (but not standard error) to a file. The net result is that messages written to standard error are sent down the pipe and the regular output of find is written to the file. The grep filters the standard output (you can decide how selective you want it to be, and may have to change the spelling depending on locale and O/S) and the final >&2 means that the surviving error messages (written to standard output) go to standard error once more. The final redirection could be regarded as optional at the terminal, but would be a very good idea to use it in a script so that error messages appear on standard error.

There are endless variations on this theme, depending on what you want to do. This will work on any variant of Unix with any Bourne shell derivative (Bash, Korn, …) and any POSIX-compliant version of find .

If you wish to adapt to the specific version of find you have on your system, there may be alternative options available. GNU find in particular has a myriad options not available in other versions — see the currently accepted answer for one such set of options.

• This answer probably goes deeper than the use case warrants, and find 2>/dev/null may be good enough in many situations. It may still be of interest for a cross-platform perspective and for its discussion of some advanced shell techniques in the interest of finding a solution that is as robust as possible, even though the cases guarded against may be largely hypothetical.

If your shell is bash or zsh , there’s a solution that is robust while being reasonably simple, using only POSIX-compliant find features; while bash itself is not part of POSIX, most modern Unix platforms come with it, making this solution widely portable:

If your system is configured to show localized error messages, prefix the find calls below with LC_ALL=C ( LC_ALL=C find . ) to ensure that English messages are reported, so that grep -v ‘Permission denied’ works as intended. Invariably, however, any error messages that do get displayed will then be in English as well.

>(. ) is a (rarely used) output process substitution that allows redirecting output (in this case, stderr output ( 2> ) to the stdin of the command inside >(. ) .
In addition to bash and zsh , ksh supports them as well in principle, but trying to combine them with redirection from stderr, as is done here ( 2> >(. ) ), appears to be silently ignored (in ksh 93u+ ).

grep -v ‘Permission denied’ filters out ( -v ) all lines (from the find command’s stderr stream) that contain the phrase Permission denied and outputs the remaining lines to stderr ( >&2 ).

Note: There’s a small chance that some of grep ‘s output may arrive after find completes, because the overall command doesn’t wait for the command inside >(. ) to finish. In bash , you can prevent this by appending | cat to the command.

This approach is:

robust: grep is only applied to error messages (and not to a combination of file paths and error messages, potentially leading to false positives), and error messages other than permission-denied ones are passed through, to stderr.

side-effect free: find ‘s exit code is preserved: the inability to access at least one of the filesystem items encountered results in exit code 1 (although that won’t tell you whether errors other than permission-denied ones occurred (too)).

POSIX-compliant solutions:

Fully POSIX-compliant solutions either have limitations or require additional work.

If find ‘s output is to be captured in a file anyway (or suppressed altogether), then the pipeline-based solution from Jonathan Leffler’s answer is simple, robust, and POSIX-compliant:

Note that the order of the redirections matters: 2>&1 must come first.

Capturing stdout output in a file up front allows 2>&1 to send only error messages through the pipeline, which grep can then unambiguously operate on.

The only downside is that the overall exit code will be the grep command’s, not find ‘s, which in this case means: if there are no errors at all or only permission-denied errors, the exit code will be 1 (signaling failure), otherwise (errors other than permission-denied ones) 0 — which is the opposite of the intent.
That said, find ‘s exit code is rarely used anyway, as it often conveys little information beyond fundamental failure such as passing a non-existent path.
However, the specific case of even only some of the input paths being inaccessible due to lack of permissions is reflected in find ‘s exit code (in both GNU and BSD find ): if a permissions-denied error occurs for any of the files processed, the exit code is set to 1 .

The following variation addresses that:

Now, the exit code indicates whether any errors other than Permission denied occurred: 1 if so, 0 otherwise.
In other words: the exit code now reflects the true intent of the command: success ( 0 ) is reported, if no errors at all or only permission-denied errors occurred.
This is arguably even better than just passing find ‘s exit code through, as in the solution at the top.

gniourf_gniourf in the comments proposes a (still POSIX-compliant) generalization of this solution using sophisticated redirections, which works even with the default behavior of printing the file paths to stdout:

In short: Custom file descriptor 3 is used to temporarily swap stdout ( 1 ) and stderr ( 2 ), so that error messages alone can be piped to grep via stdout.

Without these redirections, both data (file paths) and error messages would be piped to grep via stdout, and grep would then not be able to distinguish between error message Permission denied and a (hypothetical) file whose name happens to contain the phrase Permission denied .

As in the first solution, however, the the exit code reported will be grep ‘s, not find ‘s, but the same fix as above can be applied.

Notes on the existing answers:

There are several points to note about Michael Brux’s answer, find . ! -readable -prune -o -print :

It requires GNU find ; notably, it won’t work on macOS. Of course, if you only ever need the command to work with GNU find , this won’t be a problem for you.

Some Permission denied errors may still surface: find ! -readable -prune reports such errors for the child items of directories for which the current user does have r permission, but lacks x (executable) permission. The reason is that because the directory itself is readable, -prune is not executed, and the attempt to descend into that directory then triggers the error messages. That said, the typical case is for the r permission to be missing.

Note: The following point is a matter of philosophy and/or specific use case, and you may decide it is not relevant to you and that the command fits your needs well, especially if simply printing the paths is all you do:

• If you conceptualize the filtering of the permission-denied error messages a separate task that you want to be able to apply to any find command, then the opposite approach of proactively preventing permission-denied errors requires introducing «noise» into the find command, which also introduces complexity and logical pitfalls.
• For instance, the most up-voted comment on Michael’s answer (as of this writing) attempts to show how to extend the command by including a -name filter, as follows:
  find . ! -readable -prune -o -name ‘*.txt’
  This, however, does not work as intended, because the trailing -print action is required (an explanation can be found in this answer). Such subtleties can introduce bugs.

The first solution in Jonathan Leffler’s answer, find . 2>/dev/null > files_and_folders , as he himself states, blindly silences all error messages (and the workaround is cumbersome and not fully robust, as he also explains). Pragmatically speaking, however, it is the simplest solution, as you may be content to assume that any and all errors would be permission-related.

mist’s answer, sudo find . > files_and_folders , is concise and pragmatic, but ill-advised for anything other than merely printing filenames, for security reasons: because you’re running as the root user, «you risk having your whole system being messed up by a bug in find or a malicious version, or an incorrect invocation which writes something unexpectedly, which could not happen if you ran this with normal privileges» (from a comment on mist’s answer by tripleee).

The 2nd solution in viraptor’s answer, find . 2>&1 | grep -v ‘Permission denied’ > some_file runs the risk of false positives (due to sending a mix of stdout and stderr through the pipeline), and, potentially, instead of reporting non-permission-denied errors via stderr, captures them alongside the output paths in the output file.

Источник