Messed up my hard drive with cp!

delta_waves · 2010-02-21 05:39:46

Well, I feel like a fool right now. I was trying to copy a file I just downloaded from ktorrent to the root of my external hard drive, so I did

cp filename /dev/sdc1

thinking it would put the file at the root

not realizing that it would screw up my hard drive... is there anyway to remove this data and recover my hard drive?

Last edited by delta_waves (2010-02-21 05:53:28)

ewaller · 2010-02-21 06:31:11

Ouch.

At the very least, you have to tell us what file system used to be there. There may be a tool for your FS.

Now for the ritual beating: DO NOT use the root account for everyday use -- This is not Windows. Had you been an ordinary user, the system would not have let you do this.

delta_waves · 2010-02-21 06:35:38

Hey, I haven't been using my root account at all! If I can't do something without being root, I just type sudo.

And I believe the external drive was FAT32.

Last edited by delta_waves (2010-02-21 06:37:41)

barto · 2010-02-21 06:55:51

Hey,
for the very first thing to do I would recommend to mount this drive read-only for a while, until you recover everything you can. This is important to avoid further data loss. In this case you can size up the damages and maybe get to know foremost from AUR.

ewaller · 2010-02-21 07:08:18

delta_waves wrote:

Hey, I haven't been using my root account at all! If I can't do something without being root, I just type sudo.

Okay, okay, I take it back:P But, you didn't say you used sudo in your presentation of the problem. I think you may be in luck. I am not an expert on FAT32, but you probably have a higher chance of recovering the data than from other files systems. You might try something like http://www.cgsecurity.org/wiki/TestDisk (from a quick search of the Internet. I have no affiliation with that project)

barto · 2010-02-21 08:56:21

ewaller wrote:

But, you didn't say you used sudo in your presentation of the problem.

Cause delta_waves didn't use sudo or any kind of root priviliges. As far as I understand, he uses /dev/sdc1 as an extension of his home dir, i. e. for personal data. You don't have to be root to screw up you home dir!

ewaller · 2010-02-21 18:29:03

barto wrote:

As far as I understand, he uses /dev/sdc1 as an extension of his home dir, i. e. for personal data.

That is not what happened.

In his problem statement, delta_waves stated he had copied a file to /dev/sdc1. This means he copied a file to the file node in /dev that abstracts the first partition of sdc as a file readable and writable by the file system.

In *nix, I/O devices are (with a few exceptions) abstracted as files that live in /dev. To send characters to a serial port, redirect an output stream to /dev/ttyS0. To get random numbers, read characters from /dev/random. To make an image of a floppy disk, copy /dev/fd0 to a regular file.

when you mount a disk, you tell the mount command the location of the device node and place in the file system where you want to graft the directory structure of the partition being mounted. The appropriate file system tools then act as a go-between from operations on the abstract file system and blocks on the first partition of sdc as represented by the file /dev/sdc1.

When delta_waves copied a file directly to /dev/sdc1, he overwrote the first n bytes of the first partition on sdc1 with a new file loaded from a torrent (where n is the length of that file [more or less]) Unfortunately, FAT file systems probably store import stuff in that area -- File Allocation Tables for example. As such, the only way to recover the remainder of the data on /dev/sda1 is by doing forensics looking for signatures of files, directories, chain lists, whatever. He will have to use tools to search for them because the map that tells you how to find them has been destroyed.

The good news is that he can recover the torrent file by just copying /dev/sdc1 somewhere

Now, let me back up a bit. Of course, operating on /dev nodes can be very dangerous. That is why they are usually owned by root, and permissions are spoon fed to users using groups. On my system /dev/sda and all of its partitions /dev/sda1 - sda9 are owned by root and have read/write permissions for those in the group disk

brw-rw----  1 root disk      8,   0 Feb 20 21:02 sda                                                           
brw-rw----  1 root disk      8,   1 Feb 20 21:02 sda1                                                          
brw-rw----  1 root disk      8,   2 Feb 20 21:02 sda2                                                          
brw-rw----  1 root disk      8,   3 Feb 20 21:02 sda3                                                          
brw-rw----  1 root disk      8,   5 Feb 20 21:02 sda5                                                          
brw-rw----  1 root disk      8,   6 Feb 20 21:02 sda6                                                          
brw-rw----  1 root disk      8,   7 Feb 20 21:02 sda7                                                          
brw-rw----  1 root disk      8,   8 Feb 20 21:02 sda8                                                          
brw-rw----  1 root disk      8,   9 Feb 20 21:02 sda9

In my /etc/group I have the line disk::6:root which means root is the only person in group disk.

So going full circle, one could do what delta_waves did without using sudo or su if they added themselves to the disk group. I would not recommend adding a user directly to the disk group as a safeguard against just such a disaster.

edit -- fixed a typo

Last edited by ewaller (2010-02-21 18:31:19)

barto · 2010-02-21 23:55:20

Thank you for the extensive description.

ewaller wrote:

barto wrote:
As far as I understand, he uses /dev/sdc1 as an extension of his home dir, i. e. for personal data.
That is not what happened.

Maybe my example was not a good one. I meant that delta_waves' /dev/sdc1 was a removable hard disk, not containing any vital system data, the modification of which needed root privileges, just personal stuff. (His stating the drive to be external and the fact that he wanted to copy some torrent file to it confirmed my assumption.) Anyway, it is like a flash drive, or whatever, so the rules you described doesn't apply to it totally, because on a typical Arch system removable drives' group is not disk, but storage.

On my system, with a flash drive (sdb) plugged in (sdc is an SD card slot on it):

$ ls -l /dev/sd*
brw-rw---- 1 root disk    8,  0 febr  21 23.16 /dev/sda
brw-rw---- 1 root disk    8,  1 febr  21 07.12 /dev/sda1
brw-rw---- 1 root disk    8,  2 febr  21 07.12 /dev/sda2
brw-rw---- 1 root disk    8,  5 febr  21 07.12 /dev/sda5
brw-rw---- 1 root disk    8,  6 febr  21 07.12 /dev/sda6
brw-rw---- 1 root disk    8,  7 febr  21 07.12 /dev/sda7
brw-rw---- 1 root storage 8, 16 febr  21 23.55 /dev/sdb
brw-rw---- 1 root storage 8, 17 febr  21 23.55 /dev/sdb1
brw-rw---- 1 root storage 8, 32 febr  21 23.55 /dev/sdc

And if you set up your groups according to the Begginers' Guide, your user is in storage.
So users don't have to be root or be in the disk group to mount, format, write and yes, screw their external hard drives.

I agree with everything else you wrote. Recovery should be done by forensics, for which foremost is a possibility, in case of a FAT filesystem as well.

You are right with the "ritual beating" too. Though this is not a typical root negligence case, it can't be overemphasized, that doing anything with root privileges requires a more alert state of mind than delta wave activity, rather high beta!

ewaller · 2010-02-22 04:47:20

I love Linux because I learn something new every day.

barto wrote:

on a typical Arch system removable drives' group is not disk, but storage.
...
And if you set up your groups according to the Begginers' Guide, your user is in storage.

You are absolutely correct that these conditions would set up the permissions such that one could have user access to the file node for a device.

But here is the weird part...

On my system PATRIOT is a USB Thumb drive and SDCARD is an SD card in a non-USB card reader on my HP Pavilion DV4

ewaller@odin:~ 1105 %mount | grep vfat
/dev/sdb1 on /media/PATRIOT type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
/dev/mmcblk0p1 on /media/SDCARD type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
ewaller@odin:~ 1106 %ls -l /dev/sdb*
brw-rw---- 1 root disk 8, 16 Feb 21 17:40 /dev/sdb
brw-rw---- 1 root disk 8, 17 Feb 21 17:40 /dev/sdb1
ewaller@odin:~ 1107 %ls -l /dev/mmcblk0*
brw-rw---- 1 root disk 179, 0 Feb 21 09:42 /dev/mmcblk0
brw-rw---- 1 root disk 179, 1 Feb 21 09:42 /dev/mmcblk0p1

But I must admit, I did not RTFM

brando56894 · 2010-02-22 05:05:12

you could try and rewrite the mbr from either dos or a windows based machine and that might fix your problem. Also check out the Ultimate Boot CD as it might have something for partition recovery and stuff like that.

ewaller · 2010-02-22 05:45:20

brando56894 wrote:

you could try and rewrite the mbr from either dos or a windows based machine and that might fix your problem. Also check out the Ultimate Boot CD as it might have something for partition recovery and stuff like that.

That is a good suggestion, but here are two thoughts:

First, I would not do that to the actual drive. Preserve and protect that drive as is. Instead, I'd use dd to do a block copy of the drive to an image file on your hard disk, and then experiment with the image. One can even mount the image on a loop device (with root permissions of course, but I digress)

Second, the MBR really exists on /dev/sdc -- a file that represents the entire disk. What got stepped on was the beginning of /dev/sdc1 -- a file that represents the first partition of the drive. If the intent is to lift the first few blocks of another disk and graf them into the damaged image (using dd by-the-way) I would lift them from a partition image, not a disk image.

The thing that leaves me queasy is that most things downloaded from torrents are large -- A far cry from just a couple blocks having been stepped on.

barto · 2010-02-23 13:27:28

ewaller wrote:

I love Linux because I learn something new every day.

You are not alone, your "weird" setup surprised me as well.
But what I must admit, is having been insecure enough to R(every single line in)TFM.
I assume that there are entries for your removable devices in your fstab, or you've set up udev rules for them, and maybe this causes the difference in the groups. But I'm not sure.

Leonid.I · 2010-02-24 20:01:09

barto wrote:

on a typical Arch system removable drives' group is not disk, but storage.

If I can, let me revive my old question: Is this still true, or this functionality is given to ConsoleKit? I have seen this at
bbs.archlinux.org/viewtopic.php?id=84635&p=1
(see the second post by JCG)

Also, thanks, ewaller, for the info.

Last edited by Leonid.I (2010-02-24 20:02:25)

Arch Linux

#1 2010-02-21 05:39:46

Messed up my hard drive with cp!

#2 2010-02-21 06:31:11

Re: Messed up my hard drive with cp!

#3 2010-02-21 06:35:38

Re: Messed up my hard drive with cp!

#4 2010-02-21 06:55:51

Re: Messed up my hard drive with cp!

#5 2010-02-21 07:08:18

Re: Messed up my hard drive with cp!

#6 2010-02-21 08:56:21

Re: Messed up my hard drive with cp!

#7 2010-02-21 18:29:03

Re: Messed up my hard drive with cp!

#8 2010-02-21 23:55:20

Re: Messed up my hard drive with cp!

#9 2010-02-22 04:47:20

Re: Messed up my hard drive with cp!

#10 2010-02-22 05:05:12

Re: Messed up my hard drive with cp!

#11 2010-02-22 05:45:20

Re: Messed up my hard drive with cp!

#12 2010-02-23 13:27:28

Re: Messed up my hard drive with cp!

#13 2010-02-24 20:01:09

Re: Messed up my hard drive with cp!

Board footer