{
    "mode": "info",
    "parameter": "shred",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/shred/json",
    "generated": "2026-10-22T00:05:19Z",
    "sections": {
        "File: coreutils.info,  Node: shred invocation,  Prev: rm invocation,  Up: Basic operations": {
            "content": "",
            "subsections": [
                {
                    "name": "11.6 'shred': Remove files more securely",
                    "content": "'shred' overwrites devices or files, to help prevent even extensive\nforensics from recovering the data.\n\nOrdinarily when you remove a file (*note rm invocation::), its data\nand metadata are not actually destroyed.  Only the file's directory\nentry is removed, and the file's storage is reclaimed only when no\nprocess has the file open and no other directory entry links to the\nfile.  And even if file's data and metadata's storage space is freed for\nfurther reuse, there are undelete utilities that will attempt to\nreconstruct the file from the data in freed storage, and that can bring\nthe file back if the storage was not rewritten.\n\nOn a busy system with a nearly-full device, space can get reused in a\nfew seconds.  But there is no way to know for sure.  And although the\nundelete utilities and already-existing processes require insider or\nsuperuser access, you may be wary of the superuser, of processes running\non your behalf, or of attackers that can physically access the storage\ndevice.  So if you have sensitive data, you may want to be sure that\nrecovery is not possible by plausible attacks like these.\n\nThe best way to remove something irretrievably is to destroy the\nmedia it's on with acid, melt it down, or the like.  For cheap removable\nmedia this is often the preferred method.  However, some storage devices\nare expensive or are harder to destroy, so the 'shred' utility tries to\nachieve a similar effect non-destructively, by overwriting the file with\nnon-sensitive data.\n\n*Please note* that 'shred' relies on a crucial assumption: that the\nfile system and hardware overwrite data in place.  Although this is\ncommon and is the traditional way to do things, many modern file system\ndesigns do not satisfy this assumption.  Exceptions include:\n\n* Log-structured or journaled file systems, such as ext3/ext4 (in\n'data=journal' mode), Btrfs, NTFS, ReiserFS, XFS, ZFS, file systems\nsupplied with AIX and Solaris, etc., when they are configured to\njournal data.\n\n* File systems that write redundant data and carry on even if some\nwrites fail, such as RAID-based file systems.\n\n* File systems that make snapshots, such as Network Appliance's NFS\nserver.\n\n* File systems that cache in temporary locations, such as NFS version\n3 clients.\n\n* Compressed file systems.\n\nFor ext3 and ext4 file systems, 'shred' is less effective when the\nfile system is in 'data=journal' mode, which journals file data in\naddition to just metadata.  In both the 'data=ordered' (default) and\n'data=writeback' modes, 'shred' works as usual.  The ext3/ext4\njournaling modes can be changed by adding the 'data=something' option to\nthe mount options for a particular file system in the '/etc/fstab' file,\nas documented in the 'mount' man page ('man mount').  Alternatively, if\nyou know how large the journal is, you can shred the journal by\nshredding enough file data so that the journal cycles around and fills\nup with shredded data.\n\nIf you are not sure how your file system operates, then you should\nassume that it does not overwrite data in place, which means 'shred'\ncannot reliably operate on regular files in your file system.\n\nGenerally speaking, it is more reliable to shred a device than a\nfile, since this bypasses file system design issues mentioned above."
                }
            ]
        },
        "However, devices are also problematic for shredding, for reasons such as": {
            "content": "the following:\n\n* Solid-state storage devices (SSDs) typically do wear leveling to\nprolong service life, and this means writes are distributed to\nother blocks by the hardware, so \"overwritten\" data blocks are\nstill present in the underlying device.\n\n* Most storage devices map out bad blocks invisibly to the\napplication; if the bad blocks contain sensitive data, 'shred'\nwon't be able to destroy it.\n\n* With some obsolete storage technologies, it may be possible to take\n(say) a floppy disk back to a laboratory and use a lot of sensitive\n(and expensive) equipment to look for the faint \"echoes\" of the\noriginal data underneath the overwritten data.  With these older\ntechnologies, if the file has been overwritten only once, it's\nreputedly not even that hard.  Luckily, this kind of data recovery\nhas become difficult, and there is no public evidence that today's\nhigher-density storage devices can be analyzed in this way.\n\nThe 'shred' command can use many overwrite passes, with data\npatterns chosen to maximize the damage they do to the old data.  By\ndefault the patterns are designed for best effect on hard drives\nusing now-obsolete technology; for newer devices, a single pass\nshould suffice.  For more details, see the source code and Peter\nGutmann's paper 'Secure Deletion of Data from Magnetic and\nSolid-State Memory'\n(https://www.cs.auckland.ac.nz/~pgut001/pubs/securedel.html), from\nthe proceedings of the Sixth USENIX Security Symposium (San Jose,\nCalifornia, July 22-25, 1996).\n\n'shred' makes no attempt to detect or report these problems, just as\nit makes no attempt to do anything about backups.  However, since it is\nmore reliable to shred devices than files, 'shred' by default does not\ndeallocate or remove the output file.  This default is more suitable for\ndevices, which typically cannot be deallocated and should not be\nremoved.\n\nFinally, consider the risk of backups and mirrors.  File system\nbackups and remote mirrors may contain copies of the file that cannot be\nremoved, and that will allow a shredded file to be recovered later.  So\nif you keep any data you may later want to destroy using 'shred', be\nsure that it is not backed up or mirrored.\n\nshred [OPTION]... FILE[...]\n\nThe program accepts the following options.  Also see *note Common\noptions::.\n\n'-f'\n'--force'\nOverride file permissions if necessary to allow overwriting.\n\n'-n NUMBER'\n'--iterations=NUMBER'\nBy default, 'shred' uses 3 passes of overwrite.  You can reduce\nthis to save time, or increase it if you think it's appropriate.\nAfter 25 passes all of the internal overwrite patterns will have\nbeen used at least once.\n\n'--random-source=FILE'\nUse FILE as a source of random data used to overwrite and to choose\npass ordering.  *Note Random sources::.\n\n'-s BYTES'\n'--size=BYTES'\nShred the first BYTES bytes of the file.  The default is to shred\nthe whole file.  BYTES can be followed by a size specification like\n'K', 'M', or 'G' to specify a multiple.  *Note Block size::.\n\n'-u'\n'--remove[=HOW]'\nAfter shredding a file, deallocate it (if possible) and then remove\nit.  If a file has multiple links, only the named links will be\nremoved.  Often the file name is less sensitive than the file data,\nin which case the optional HOW parameter, supported with the long\nform option, gives control of how to more efficiently remove each\ndirectory entry.  The 'unlink' parameter will just use a standard\nunlink call, 'wipe' will also first obfuscate bytes in the name,\nand 'wipesync' will also sync each obfuscated byte in the name to\nthe file system.  Note 'wipesync' is the default method, but can be\nexpensive, requiring a sync for every character in every file.\nThis can become significant with many files, or is redundant if\nyour file system provides synchronous metadata updates.\n\n'-v'\n'--verbose'\nDisplay to standard error all status updates as sterilization\nproceeds.\n\n'-x'\n'--exact'\nBy default, 'shred' rounds the size of a regular file up to the\nnext multiple of the file system block size to fully erase the\nslack space in the last block of the file.  This space may contain\nportions of the current system memory on some systems for example.\nUse '--exact' to suppress that behavior.  Thus, by default if you\nshred a 10-byte regular file on a system with 512-byte blocks, the\nresulting file will be 512 bytes long.  With this option, shred\ndoes not increase the apparent size of the file.\n\n'-z'\n'--zero'\nNormally, the last pass that 'shred' writes is made up of random\ndata.  If this would be conspicuous on your storage device (for\nexample, because it looks like encrypted data), or you just think\nit's tidier, the '--zero' option adds an additional overwrite pass\nwith all zero bits.  This is in addition to the number of passes\nspecified by the '--iterations' option.\n\nYou might use the following command to erase the file system you\ncreated on a USB flash drive.  This command typically takes several\nminutes, depending on the drive's size and write speed.  On modern\nstorage devices a single pass should be adequate, and will take one\nthird the time of the default three-pass approach.\n\nshred -v -n 1 /dev/sdd1\n\nSimilarly, to erase all data on a selected partition of your device,\nyou could give a command like the following.\n\n# 1 pass, write pseudo-random data; 3x faster than the default\nshred -v -n1 /dev/sda5\n\nTo be on the safe side, use at least one pass that overwrites using\npseudo-random data.  I.e., don't be tempted to use '-n0 --zero', in case\nsome device controller optimizes the process of writing blocks of all\nzeros, and thereby does not clear all bytes in a block.  Some SSDs may\ndo just that.\n\nA FILE of '-' denotes standard output.  The intended use of this is\nto shred a removed temporary file.  For example:\n\ni=$(mktemp)\nexec 3<>\"$i\"\nrm -- \"$i\"\necho \"Hello, world\" >&3\nshred - >&3\nexec 3>-\n\nHowever, the command 'shred - >file' does not shred the contents of\nFILE, since the shell truncates FILE before invoking 'shred'.  Use the\ncommand 'shred file' or (if using a Bourne-compatible shell) the command\n'shred - 1<>file' instead.\n\nAn exit status of zero indicates success, and a nonzero value\nindicates failure.\n",
            "subsections": []
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}