Unix & Linux: How do I recursively shred an entire directory tree? (7 Solutions!!)
Channel: Roel Van de Paar
Date: 13/08/2020

Unix & Linux: How do I recursively shred an entire directory tree?


The Question: 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?

Solutions: Please watch the whole video to see all solutions, in order of how many people found them helpful

== This solution helped 5 people ==
find /your/directory -exec shred {} ;

== This solution helped 49 people ==
Use the find command to execute shred recursively:
find ＜dir＞ -type f -exec shred {} ;

== This solution helped 4 people ==
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).

== This solution helped 28 people ==
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.

With thanks & praise to God, and with thanks to the many people who have made this project possible! | Content (except music & images) licensed under cc by-sa 3.0 | Music: https://www.bensound.com/royalty-free-music | Images: https://stocksnap.io/license & others | With thanks to user user unknown (https://unix.stackexchange.com/users/4485), user telotortium (https://unix.stackexchange.com/users/21394), user Steve V. (https://unix.stackexchange.com/users/3056), user legends2k (https://unix.stackexchange.com/users/30580), user JoelAZ (https://unix.stackexchange.com/users/67310), user jamesallman (https://unix.stackexchange.com/users/8025), user im3r3k (https://unix.stackexchange.com/users/61788), user Gilles 'SO- stop being evil' (https://unix.stackexchange.com/users/885), user Cookie (https://unix.stackexchange.com/users/7913), user Alexis Wilke (https://unix.stackexchange.com/users/57773), user Alexander (https://unix.stackexchange.com/users/3920), and the Stack Exchange Network (http://unix.stackexchange.com/questions/27027). Trademarks are property of their respective owners. Disclaimer: All information is provided "AS IS" without warranty of any kind. You are responsible for your own actions. Please contact me if anything is amiss at Roel D.OT VandePaar A.T gmail.com.