Hard Drive Rehab Effort after Crash

rknichols · 03-07-2017, 01:04 PM

Quote:

Originally Posted by GNewbie

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 $

But what is the output from just "id" (with no arguments). That is what shows who you are now.

Quote:

Please note that I have...

1. I created another user named "everyone" with the exact username and password as on the original encrypted drive.

That user name will not have the same numeric UID as before, and that is what matters.

Quote:

Also note that "main" is the name of the initial user on my new installation (the one I'm using now).

So you say, but getting permission denied when trying to access /mnt/tmp/everyone suggests that this is not the case. Again, what does just "id" with no arguments show?

Quote:

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.

Since there is no way to do that, I don't know what you think you did. Show the exact mount command, please. The numeric UID and GID is recorded in every inode in that filesystem. The ls command will just map those numbers into user names and group names by using the current /etc/passwd and /etc/group files.

Quote:

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 #

Don't worry about those. The "gvfs" directory contains nodes and links that are meaningful only to tools in the current Gnome session. Programs that are not connected to that session cannot access there. And anyway, "/run/user/nnnn/gvfs" is not part of the filesystem you have mounted on /mnt/tmp.

Quote:

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?

That's not going to work. The target of a chroot needs to contain all of the programs, libraries, and configuration files that you need there. That's not going to be the case for a filesystem that was just an image containing home directories.

GNewbie · 03-07-2017, 02:17 PM

Quote:

Originally Posted by rknichols

But what is the output from just "id" (with no arguments). That is what shows who you are now.

That user name will not have the same numeric UID as before, and that is what matters.
So you say, but getting permission denied when trying to access /mnt/tmp/everyone suggests that this is not the case. Again, what does just "id" with no arguments show? Since there is no way to do that, I don't know what you think you did. Show the exact mount command, please. The numeric UID and GID is recorded in every inode in that filesystem. The ls command will just map those numbers into user names and group names by using the current /etc/passwd and /etc/group files.

Don't worry about those. The "gvfs" directory contains nodes and links that are meaningful only to tools in the current Gnome session. Programs that are not connected to that session cannot access there. And anyway, "/run/user/nnnn/gvfs" is not part of the filesystem you have mounted on /mnt/tmp.
That's not going to work. The target of a chroot needs to contain all of the programs, libraries, and configuration files that you need there. That's not going to be the case for a filesystem that was just an image containing home directories.

1. id command with no arguments displayed following for everyone root and everyone in /mnt, /tmp, and the /everyone directory:

As user everyone in root mode:

Code:

main-desktop mnt # id
uid=0(root) gid=0(root) groups=0(root)
main-desktop mnt #

main-desktop tmp # id
uid=0(root) gid=0(root) groups=0(root)
main-desktop tmp #

main-desktop everyone # id
uid=0(root) gid=0(root) groups=0(root)
main-desktop everyone #

As user everyone:

Code:

everyone@main-desktop /mnt $ id
uid=1002(everyone) gid=1002(everyone) groups=1002(everyone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),130(sambashare),1000(main)
everyone@main-desktop /mnt $ 

everyone@main-desktop /mnt/tmp $ id
uid=1002(everyone) gid=1002(everyone) groups=1002(everyone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),130(sambashare),1000(main)
everyone@main-desktop /mnt/tmp $

2. The exact mount command I used was,

Code:

everyone@main-desktop ~ $ sudo mount -o ro,loop /media/everyone/...path_to.../homebackup.img /mnt/tmp
everyone@main-desktop ~ $

When I run the mount command, the line below displays. Does it mean that the image file is mounted?

Code:

/media/everyone/...path_to.../homebackup.img on /mnt/tmp type ext4 (ro,relatime,data=ordered)

Do I need to get the UID of everyone off of the original damaged hard drive?

rknichols · 03-07-2017, 04:52 PM

You misunderstand. The id command shows what your current UID is, regardless of where you are. When you are running as root, your current UID will be 0. I see that the UID for user "everyone" is 1002, which, as expected, does not match the UID 1000 that owns the /mnt/tmp/everyone directory. That is why you cannot enter that directory as user "everyone". Based on what you previously posted, you should be able to browse in that directory while running as user "main" (UID=1000).

Quote:

2. The exact mount command I used was,

Code:

everyone@main-desktop ~ $ sudo mount -o ro,loop /media/everyone/...path_to.../homebackup.img /mnt/tmp
everyone@main-desktop ~ $

When I run the mount command, the line below displays. Does it mean that the image file is mounted?

Code:

/media/everyone/...path_to.../homebackup.img on /mnt/tmp type ext4 (ro,relatime,data=ordered)

Do I need to get the UID of everyone off of the original damaged hard drive?

The image is mounted read-only as expected. The only UID that appears to be of importance is the one for "everyone", and that is already known to be 1000.

I'm really the wrong person to aid with recovering eCryptfs data. I've never used it, and I have no idea how Ubuntu sets it up. Does this image file include the entire home directory for user "everyone"? There are dotfiles in a user's home directory that, depending on how eCryptfs was set up, could be essential to unlocking the encrypted directories.