LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 03-03-2017, 02:56 PM   #16
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31

Quote:
Originally Posted by rknichols View Post
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.
 
Old 03-03-2017, 05:13 PM   #17
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.

Last edited by rknichols; 03-03-2017 at 05:15 PM.
 
Old 03-04-2017, 08:23 PM   #18
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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?
 
Old 03-04-2017, 09:25 PM   #19
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.
 
Old 03-05-2017, 08:20 AM   #20
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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.

Last edited by GNewbie; 03-05-2017 at 08:22 AM.
 
Old 03-05-2017, 09:35 AM   #21
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.
 
Old 03-05-2017, 01:00 PM   #22
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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 View Post
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.
 
Old 03-05-2017, 01:54 PM   #23
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
Quote:
Originally Posted by GNewbie View Post
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.
 
Old 03-06-2017, 12:22 AM   #24
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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 View Post
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...
 
Old 03-06-2017, 07:49 AM   #25
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.
 
Old 03-06-2017, 07:01 PM   #26
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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...
 
Old 03-06-2017, 07:24 PM   #27
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
Quote:
Originally Posted by GNewbie View Post
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
 
Old 03-06-2017, 09:18 PM   #28
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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.
 
Old 03-06-2017, 11:48 PM   #29
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.
 
Old 03-07-2017, 12:25 PM   #30
GNewbie
Member
 
Registered: Sep 2005
Distribution: (U/K/X)buntu 6.1 (newer box) / D*mn Small Linux (older box)
Posts: 318

Original Poster
Rep: Reputation: 31
Quote:
Originally Posted by rknichols View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Drive Hard Crash kevinbenko Linux - Hardware 18 04-25-2016 10:26 AM
hard drive crash sandie1 Linux - Security 1 02-06-2011 09:13 PM
[SOLVED] Hardware crash,Repaired,New Install New Hard drive,how to access original Hard drive flatstan Linux - Hardware 7 07-21-2009 07:51 PM
HELP! Hard Drive crash Stew Pididiot Linux - Newbie 9 11-21-2005 06:45 AM
Hard Drive crash -- NEED HELP! Stew Pididiot Linux - General 2 10-28-2005 06:32 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 04:23 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration