Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a directory tree that I would like to shred with the Linux 'shred' utility. Unfortunately, shred has no -R option for recursive shredding.

How can I shred an entire directory tree recursively?

share|improve this question

migrated from stackoverflow.com Dec 17 '11 at 5:46

This question came from our site for professional and enthusiast programmers.

up vote 21 down vote accepted

Use the find command to execute shred recursively:

find <dir> -type f -exec shred {} \;
share|improve this answer
Does it work without the -depth option? Does it work on modern, journaling file systems? – user unknown Dec 17 '11 at 20:08
@userunknown No, shred does not work on modern journaling file systems. For more precise information, please see man shred. – FanaticD May 10 at 14:39

Beware of shred!

From the shred-manpage:

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:

  • log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

  • file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

  • file systems that make snapshots, such as Network Appliance's NFS server

  • file systems that cache in temporary locations, such as NFS version 3 clients

  • compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount).

In addition, file system backups and remote mirrors may contain copies of the file that cannot be removed, and that will allow a shredded file to be recovered later.

Solution: Use an encrypted filesystem, and just delete your files.

share|improve this answer
+1 for pointer on shred, I had a similar case before. It did not work on NetApp's NFS. NetApp uses WAFL and which uses copy-on-write including metajournalling, so its right. Also with latest Solaris' ZFS is another case where shred sheds. – Nikhil Mulley Dec 17 '11 at 20:26
This is a bad solution. An encrypted file system is only safe so long as it locked (and so unmounted). As soon as your OS is up and running, the data is up-for-grabs. – oleks Sep 17 '15 at 12:30

Combining this answer with the best known options for shred using this stack overflow link 'Deleting Files Permanently and Securely on CentOS':

find <directory> -depth -type f -exec shred -v -n 1 -z -u {} \;

Edit: Be aware that best answer for shredding a single file forces a sync which writes changes to the media before deleting the file because some or all journaled filesystems have a buffer.

If possible, the find command should call a shell script on the file which runs:

shred -v -n 1 /path/to/your/file #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u /path/to/your/file #overwriting with zeroes and remove the file

on each file.

share|improve this answer
After reading and researching many answers, I found (imho) this answer to be the most thorough. I would only add to it that since shred does not remove directories I appended rm -rvf $1 to the shell script (where $1 is the /path/to/your/file passed in from the {} expansion in the find... -exec) – JoelAZ Jul 4 '14 at 5:44
shred already does a fsync(2) after each pass. Precisely because you need to force the file changes to reach the disk before the next pass. – Ángel Jan 2 at 15:49
find /your/directory -exec shred {} \;
share|improve this answer
Upvoted, but James beat you by one minute for the accept. – Steve V. Dec 17 '11 at 6:19
Does it work without the -depth option? Does it work on modern, journaling file systems? – user unknown Dec 17 '11 at 20:08
find [dirname] -depth -type f -exec shred -n1 {} \;

This performs a depth-first search for files in directory [dirname], then runs the shred -n1 command on each file. When removing files and/or directories, adding -depth as default is a good habit, even though it's not strictly needed for this case. When running this sort of command with rm -rf instead of shred, -depth is needed to ensure that directories are not deleted before the contents of the directories are attempted to be deleted (thus causing errors).

share|improve this answer
You should use shred -N 1, because the default, shredding 3 times, is snake oil. Either one time is sufficient, or 30 times will not work. – user unknown Dec 17 '11 at 20:11
Providing a simple command as an answer isn't the best way to answer a question. I would recommend adding a small explanation about what the line is doing and the possible limitations involved with using it. – n0pe Dec 18 '11 at 13:39
Thanks user unknown, added -N1 – Alexander Dec 18 '11 at 14:12

Use secure delete instead.

sudo apt-get install secure-delete
srm -r pathname

Done. Secure delete is a lot more paranoid than shred, using 38 passes instead of 3. To do a fast single pass, use

srm -rfll pathname

fll gets you a less random random data generator, and only a single pass.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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