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?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityUse the find
command to execute shred
recursively:
find <dir> -type f -exec shred {} \;
man shred
.
-exec shred {} +
to make it faster since shred accepts multiple arguments.
-exec shred --remove=wipe {} +
will also attempt to obliterate the filenames - although still with the caveat that it's hard to be sure something is really gone from modern filesystems and storage devices.
--remove=wipesync
will do what wipe does but additionally ensure the obfuscated bytes are synced to disk. This can be more expensive but makes sure nothing is left behind (keep in mind shred's disclaimer). Note that wipesync
is the default behavior if you supply -u
. (based on shred version 8.31)
Aug 18, 2020 at 19:57
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.
Also, SSDs might thwart your attempts of overwriting data.
Solution: Use an encrypted filesystem, and just delete your files.
shred
and data encryption prevent reading the data off an offline storage device (think theft or police) with data encryption having the added benefit of protecting all files, not just the ones (properly) deleted. Once the file system is mounted we're back to good ol' unix permissions in either case and data protection becomes a task of OS security and proper system administration again. Upfront filesystem encryption is definitely not worse at protecting data at rest than strategic usage of shred
!
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 data generator, and only a single pass.
find
-based methods that will try to also erase stored filenames by renaming files before truncating and unlinking them.
srm -rfll
v3.1 seems noticeably slower than the find -exec shred
alternatives, as if it is still syncing even though asked not to.
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.
rm -rvf $1
to the shell script (where $1 is the /path/to/your/file passed in from the {}
expansion in the find... -exec
)
';'
would do instead of \;
find /your/directory -exec shred {} \;
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).
The most thorough shred
method I've found, which includes directory removal too, is to have find
call a script to have shred
:
This method also properly handles filenames with spaces in them.
First - the shred
script (I've named mine dirShredder.sh
and stored it in the /root
directory:
shred -v -n 1 "$1" #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u "$1" #overwriting with zeroes and remove the file
rm -rvf "$1" # call rm to remove the directories
Then, call the script like this:
find /volume1/pathToShred/ -mindepth 1 -depth -exec /root/dirShredder.sh "{}" \;
Make sure to mark the killit.sh
file executable (chmod +x
) and of course update the path for the dir you want to shred and to dirShredder.sh
if you store it somewhere else.
NOTA BENE - shred
has issues on Copy-on-Write filesystems (ZFS, BTRFS, et al) and even on Journaling file systems. There is no real accepted "best" way to deal with this that I've found other than "encrypted filesystems" but I'm not sure how effective this is after-the-fact.
The closest it seems you can get is to overwrite all empty space on the drive with random data after your shredding ops (not zeros, seems this is not always reliable.) Also, SSDs may have other considerations too (like TRIM.)
I'm not going into those here, there are other Stack answers (@user unknown's answer in this question for example) and plenty of discussions throughout the 'net that cover these topics so search them out if you need that level of security.