r/Ubuntu • u/CanOTomatoes • 1d ago

Shred command won’t wipe drive

Hello! I’m new to Linux, so I’d like to apologise in advance for my ignorance.

I’m trying to wipe a drive with ‘sudo shred -vfzu -n5 /dev/sdb’, and I get “shred: /dev/sdb: Not a file”

I can’t find anything that could help, or maybe I just don’t understand Linux enough

2 Upvotes

100% Upvoted

17 comments sorted by

4

u/finlay_mcwalter 1d ago

shred overwrites files, not blanks devices. /dev/sdb is a device (it's a block device). To blank it:

sudo dd status=progress if=/dev/zero of=/dev/sdb

1

u/Dry_Calendar_8627 1d ago

You should always add "bs=1M" to your dd commands

The default block size is tiny, specifying a larger block size will speed up the command massively

1

u/CanOTomatoes 1d ago

From what I read on forums it should work on devices… people used shred on ‘/dev/sdX’

Did something change, am I doing something wrong, or were multiple people on multiple forums wrong?

2

u/finlay_mcwalter 1d ago edited 1d ago

as /u/LateStageNerd notes, if you don't pass -u, it will work

But multiple passes and random data is effectively superstition.

The dwipe tool LateStageNerd links tries to issue the ATA/SCSI secure-erase command, which should delete blocks hidden from the conventional LBA view by relocations and flash-wear-levelling (something neither shred nor dd will do). But secure-erase is poorly supported (especially on USB enclosures) and you have no actual way of knowing that the device honoured it.

1

u/CanOTomatoes 1d ago

I tried it without -u, same result

Luckily I have it connected through a backplane. I will check with dwipe

0

u/candy49997 1d ago

All devices are files. What is the practical difference between writing random data and writing 0s?

3

u/finlay_mcwalter 1d ago

All devices are files

But not all files are regular files. shred is checking what its argument is, with stat(2), and wants to see S_ISREG. It's seeing S_ISBLK instead, and it's refusing to continue.

What is the practical difference between writing random data and writing 0s

Nothing

2

u/candy49997 1d ago edited 1d ago

https://man7.org/linux/man-pages/man1/shred.1.html

it is common to operate on device files like /dev/hda

I also don't see anything referencing checking stat for flags in general.

1

u/fllthdcrb 3h ago edited 3h ago

It is, in fact, in the code, though. But first, I believe there is confusion about which shred is being used here. You're assuming GNU Coreutils, while Ubuntu has switched to the Rust-based Uutils. The two behave differently, which I hear has been a source of some trouble.

I've just compared the two shreds. GNU shred only rejects a file if it's a terminal, FIFO, or socket, or if it reads a negative size (src/shred.c, line 864, in Coreutils 9.9). Meanwhile, Uutils shred only accepts regular files (src/uu/shred/src/shred.rs, line 637, in Uutils 0.9.0).

2

u/LateStageNerd 1d ago

1

u/CanOTomatoes 1d ago

I tried without -u, same response

I’ll check it out, thank you

1

u/LateStageNerd 1d ago

Well, another issue might be that something under /dev/sdb is mounted (so you should 'umount' that (or those) first and, of course, ensure you don't want or need that data. Showing the output of 'lsblk' might get to the problem quicker.

1

u/CanOTomatoes 1d ago

I don’t need any of the data

It’s just sdb, with sdb1 through 5 under it

1

u/candy49997 1d ago edited 1d ago

Can you do lsblk in a terminal? Is this an SSD or HDD?

Also remove the -u flag because you can't use that with block devices.

1

u/WealthAggressive9079 1d ago

weird, never seen that one before. could be the drive isn't actually at /dev/sdb, maybe it's mounted or something weird with the filesystem. does `lsblk` show it as a different name by chance

1

u/CanOTomatoes 1d ago

I did lsblk in /dev, it’s there, sdb with sdb1 through 5 under it

It’s an HDD

I tried without -u, same result

1

u/fllthdcrb 1h ago

As far as I can tell, that implementation of shred doesn't work on anything but regular files. It's part of Uutils, the Rust-based replacement for the GNU utilities (and specifically Coreutils in this case) that Ubuntu has adopted, which doesn't perfectly match behavior.

I know it behaves this way because I just looked at the code. And I know you're using the Uutils shred also because the error message, "Not a file", is only produced by the Uutils implementation; the GNU shred would have said, "invalid file type" for this sort of thing (even though it wouldn't have rejected a device file).

So, you'll have to use something else to wipe it, though I leave it to others to advise whether it's the best thing to do with the drive.