Hard Drive Rehab Effort after Crash

GNewbie · 03-03-2017, 01:56 PM

Quote:

Originally Posted by rknichols

The name doesn't matter. Now that you know the path to the image file, just run testdisk on that file and select "none" (Non partitioned media) as the partition table type.

You could also just try running "fsck.ext4 /path/to/hdbackup.img". It should find the backup super blocks automatically. But, do NOT do this on your only copy of that image, especially not with the "-y" option. The job of fsck is to make the filesystem consistent. To do that, it will sometimes make otherwise recoverable data much harder to extract.

I don't know what "just run testdisk on that file and select "none" (Non partitioned media) as the partition table type" means because there are options that appear I do exactly that. I don't what options to choose.

Yes, I'm a total testdisk newb, which is good in a sense (not previous disabled partition), but bad also bad in a sense (because I don't know what I'm doing now).

These are my options:

Code:

 [ Analyse  ] Analyse current partition structure and search for lost partitions
 [ Advanced ] Filesystem Utils
 [ Geometry ] Change disk geometry
 [ Options  ] Modify options
 [ Quit     ] Return to disk selection

Which one should I choose, and what are the associated details if there is a decision-tree that follows the choice.

Thanks for the help, and I appreciate your patience.

rknichols · 03-03-2017, 04:13 PM

testdisk will probably pre-select "Advanced", and in that Filesystem Utils menu pre-select "Superblock". Running that will give you a list of the backup super blocks found and instructions for running fsck.ext4 with the "-p" (preen) and "-b" (superblock) options. That fsck command will probably terminate with an "UNEXPECTED INCONSISTENCY" message, but in the process will have reconstructed the primary super block.

The filesystem will probably still be too damaged to mount, but by running testdisk again you should now be able to enter the Filesystem Utils menu and select "List", which will allow you to see and copy files. If there were a few critical files you wanted to recover, you could do that. Otherwise, you can run fsck with the "-y" option on the image file and let it patch the filesystem back together. Then you should be able to mount that image and see what you've got.

GNewbie · 03-04-2017, 07:23 PM

Quote:

Originally Posted by rknichols

testdisk will probably pre-select "Advanced", and in that Filesystem Utils menu pre-select "Superblock". Running that will give you a list of the backup super blocks found and instructions for running fsck.ext4 with the "-p" (preen) and "-b" (superblock) options. That fsck command will probably terminate with an "UNEXPECTED INCONSISTENCY" message, but in the process will have reconstructed the primary super block.

The filesystem will probably still be too damaged to mount, but by running testdisk again you should now be able to enter the Filesystem Utils menu and select "List", which will allow you to see and copy files. If there were a few critical files you wanted to recover, you could do that. Otherwise, you can run fsck with the "-y" option on the image file and let it patch the filesystem back together. Then you should be able to mount that image and see what you've got.

I ran testdisk, I found the main superblock, I ran fsck as directed and came up with the following error:

Code:

$ sudo fsck.ext4 -p -b 32768 -B 4096 /media/...path to file...
/media/main/homebackup.img was not cleanly unmounted, check forced.
/media/main/homebackup.img: Resize inode not valid.  

/media/main/homebackup.img: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

Is it safe to run the fsck option without the (-p) flag?

rknichols · 03-04-2017, 08:25 PM

Since you do have another copy of that image, there is little to lose by running "fsck -y /media/...path to file...". Even in the worst case if fsck makes a mess of parts of the filesystem, you can still get back to where you were. As I said before, your other option is to use testdisk again, select "Advanced" and then "List", and you will have the opportunity to save files from the image in its current state. It's your choice.

GNewbie · 03-05-2017, 07:20 AM

Quote:

Originally Posted by rknichols

Since you do have another copy of that image, there is little to lose by running "fsck -y /media/...path to file...". Even in the worst case if fsck makes a mess of parts of the filesystem, you can still get back to where you were. As I said before, your other option is to use testdisk again, select "Advanced" and then "List", and you will have the opportunity to save files from the image in its current state. It's your choice.

OK, I think I have access to the file system in testdisk. I'm looking at the following screen, but I don't know what I'm supposed to do.

Code:

Directory /user
>dr-x------  1000  1000      4096  6-Apr-2014 16:13 .
 drwxr-xr-x     0     0      4096  6-Apr-2014 16:13 ..
 lrwxrwxrwx  1000  1000        34  6-Apr-2014 16:13 .ecryptfs
 lrwxrwxrwx  1000  1000        33  6-Apr-2014 16:13 .Private
 lrwxrwxrwx  1000  1000        52  6-Apr-2014 16:13 README.txt
 lrwxrwxrwx  1000  1000        56  6-Apr-2014 16:13 Access-Your-Private-Data.desktop

I tried to access Access-Your-Private-Data.desktop, but nothing happened. I believe the partition was encrypted (but not sure), but I know the password.

Update, OK, I saw the select ":" to select the file. I have to run now, but I've selected the Access-Your-Private-Data.desktop, and I'm waiting until I get back to press enter and see what happens.

rknichols · 03-05-2017, 08:35 AM

That "Access-Your-Private-Data.desktop" is just a symbolic link, not the actual file. I see you are using "eCryptfs". As far as I know, testdisk will be able to access only the encrypted version of those directories, and you will also see only encrypted filenames. That's going to make it hard to recover those files with testdisk.

GNewbie · 03-05-2017, 12:00 PM

Quote:

Originally Posted by rknichols

That "Access-Your-Private-Data.desktop" is just a symbolic link, not the actual file. I see you are using "eCryptfs". As far as I know, testdisk will be able to access only the encrypted version of those directories, and you will also see only encrypted filenames. That's going to make it hard to recover those files with testdisk.

So I navigated a bit through testdisk and came across a bunch of file names like:

Code:

 drwxr-xr-x  1000  1000      4096 28-Oct-2014 22:36 ECRYPTFS_FNEK_ENCRYPTED...

There is no indication as to what each of these files is.

Previously you said...

Quote:

Originally Posted by rknichols

Otherwise, you can run fsck with the "-y" option on the image file and let it patch the filesystem back together. Then you should be able to mount that image and see what you've got.

Can I follow that fsck procedure outlined in the above comment to try and make the homeback.img file mountable and then try to use ecryptfs-recover-private to try and access the drive?

Do to the problem encountered as described below, do I need to do run fsck without the -p flag?

Code:

$ sudo fsck.ext4 -p -b 32768 -B 4096 /media/...path to file...
/media/main/homebackup.img was not cleanly unmounted, check forced.
/media/main/homebackup.img: Resize inode not valid.  

/media/main/homebackup.img: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
	(i.e., without -a or -p options)

Or can I go straight to...

Code:

"fsck -y /media/...path to image file..."

...to see if the image file can be made mountable?

Thanks, and I really appreciate your patience and perseverance with my issue.

rknichols · 03-05-2017, 12:54 PM

Quote:

Originally Posted by GNewbie

Code:

"fsck -y /media/...path to image file..."

...to see if the image file can be made mountable?

That will make the file mountable. You will get an idea of how much damage might have been done to your data by how many screenfulls of messages scroll by during the repair.

GNewbie · 03-05-2017, 11:22 PM

Quote:

Originally Posted by rknichols

That will make the file mountable. You will get an idea of how much damage might have been done to your data by how many screenfulls of messages scroll by during the repair.

Quote:

Originally Posted by rknichols

That will make the file mountable. You will get an idea of how much damage might have been done to your data by how many screenfulls of messages scroll by during the repair.

And the answer is... 3.5% non-contiguous.

Code:

/path_to/hdbackup.img: ***** FILE SYSTEM WAS MODIFIED *****
/media/path_to/hdbackup.img: 130267/54935552 files (3.5% non-contiguous), 208708757/219726336 blocks

Do you have any clues as to how I can mount that image file with ecryptfs? Do I need to create a use of the same name as on the original drive to try to access it

TIA...

rknichols · 03-06-2017, 06:49 AM

You can mount the image (I suggest read-only) with "mount -o ro,loop /media/path_to/hdbackup.img /mnt/tmp". The directory /mnt/tmp, must already exist. I have no experience with eCryptfs, but https://wiki.archlinux.org/index.php...s#Manual_setup shows how to access an encrypted directory that is not at the location assumed by the "convenience" tools. I believe that Ubuntu defaults to using your login password as the encryption passphrase, but I don't know the details. That's about all I can offer.

GNewbie · 03-06-2017, 06:01 PM

Quote:

Originally Posted by rknichols

You can mount the image (I suggest read-only) with "mount -o ro,loop /media/path_to/hdbackup.img /mnt/tmp". The directory /mnt/tmp, must already exist. I have no experience with eCryptfs, but https://wiki.archlinux.org/index.php...s#Manual_setup shows how to access an encrypted directory that is not at the location assumed by the "convenience" tools. I believe that Ubuntu defaults to using your login password as the encryption passphrase, but I don't know the details. That's about all I can offer.

Hi rk,

The following error was returned after following the instructions...

Code:

mount: can't find /media/user/[path to partition on which the file is located] in /etc/fstab

Note that the error pointed to the partition on which the file resides and not to the file itself.

Do you have any advice as to resolve this?

TIA...

rknichols · 03-06-2017, 06:24 PM

Quote:

Originally Posted by GNewbie

Hi rk,

The following error was returned after following the instructions...

Code:

mount: can't find /media/user/[path to partition on which the file is located] in /etc/fstab

Note that the error pointed to the partition on which the file resides and not to the file itself.

Do you have any advice as to resolve this?

TIA...

What was the full mount command that you used? When you give the mount command both the device and the mount point directory, it won't look at /etc/fstab at all. Note that if either one of those arguments contain embedded space characters, the argument will have to be quoted.

Code:

mount -o ro,loop /media/path_to/hdbackup.img  /mnt/tmp
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^
                           device            mount point

GNewbie · 03-06-2017, 08:18 PM

Quote:

Originally Posted by rknichols

What was the full mount command that you used? When you give the mount command both the device and the mount point directory, it won't look at /etc/fstab at all. Note that if either one of those arguments contain embedded space characters, the argument will have to be quoted.

Code:

mount -o ro,loop /media/path_to/hdbackup.img  /mnt/tmp
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^
                           device            mount point

I believe I left of the " /mnt/tmp" portion. I tried again. My /mnt/tmp file contained a directory with the name of the user on the old hard drive, but when I tried to access it, I received the following message.

Code:

You do not have the permissions necessary to view the contents of "everyone".

I will embark on the next stage of my journey - to try and find how to access the directory given it encrypted.

I really appreciate your patience and support in getting me this far.

Thank you very, very much.

rknichols · 03-06-2017, 10:48 PM

You need to be accessing that directory either as "root" or with the same numeric UID as the directory owner. You can see that UID by running "ls -ld /mnt/tmp/everyone" (adjust that path as needed) and see your current UID by running the id command. You could (a) explore in a terminal session as root by running "sudo -i", (b) use the adduser command to create a user with the appropriate numeric UID, or (c) use the chown command to change the ownership of the "everyone" directory and its contents to your current UID.

GNewbie · 03-07-2017, 11:25 AM

Quote:

Originally Posted by rknichols

You need to be accessing that directory either as "root" or with the same numeric UID as the directory owner. You can see that UID by running "ls -ld /mnt/tmp/everyone" (adjust that path as needed) and see your current UID by running the id command. You could (a) explore in a terminal session as root by running "sudo -i", (b) use the adduser command to create a user with the appropriate numeric UID, or (c) use the chown command to change the ownership of the "everyone" directory and its contents to your current UID.

Hi rk,

I followed you instructions with the following results:

Code:

everyone@main-desktop /mnt/tmp $ ls -ld /mnt/tmp/everyone
dr-x------ 2 main main 4096 Apr  6  2014 /mnt/tmp/everyone
everyone@main-desktop /mnt/tmp $ id main
uid=1000(main) gid=1000(main) groups=1000(main),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),130(sambashare)
everyone@main-desktop /mnt/tmp $

Please note that I have...

1. I created another user named "everyone" with the exact username and password as on the original encrypted drive.
2. I gave user everyone an Administrator account type, and gave it access to all the same groups as the originating user on my new hard drive.

Also note that "main" is the name of the initial user on my new installation (the one I'm using now). I mounted the USB using user everyone, so it isn't obvious why the originating user of this installation is the one that comes up when the id command is used.

-----------------------------------

I also tried the following...

3. I'm trying to access homebackup.img (which is on a USB drive) from the everyone user account (same name and password as the original partition).
4. I elevated privileges in Nemo to that of a root user (logged in as everyone), I navigated to /mnt/tmp, I opened a terminal, and I ran the following command using sudo:

Code:

... tmp # sudo ecryptfs-recover-private
INFO: Searching for encrypted private directories (this might take a while)...
find: ‘/run/user/1002/gvfs’: Permission denied
find: ‘/run/user/1000/gvfs’: Permission denied
... tmp #

I did a quick search of permission denied line and found this...

ecryptfs-recover-private cannot find encrypted home folder
http://askubuntu.com/questions/87567...ed-home-folder

The solution provided in the original poster's case was to...

Quote:

I found the answer by trial and error: essentially, I needed to do sudo chroot /mnt then run ecryptfs-recover-private. I was then prompted for the Login password and successfully gained access..

I've noted my current permission settings for my /mnt directory. Should I...

Code:

sudo chroot /mnt

...and then try again? I almost did, but then I decided it would be better to check in here. I don't know if that is the whole command or if it requires some options. Heck, I don't even know if it makes sense in my specific case.