3

My laptop is failing, but I know for sure the hard drive is okay and fine.

I want to take the data inside it, I connect my laptop's hard drive (open suse tumbleweed with btrfs filesystem) to my desktop pc (ubuntu 22.04.01 LTS with vfat filesystem), It could access the hard drive it show some linux system directory on it (bin,boot,cdrom,dev,etc,home and the rest) but when I browse the directory there is nothing on it

How to gain access to those data? I know the username and the password and the root's passwords

I have a guts its must be some permission or something and I also have a guts its should be like when people talking about saving ur data with live cd but yeah I don't know how to gain access to those data.

here is my lsblk

~ $ sudo lsblk -o +fstype | grep -v /snap/
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS                                    FSTYPE
sda      8:0    0 223,6G  0 disk                                                
├─sda1   8:1    0   512M  0 part /boot/efi                                      vfat
                                 /                                              
sdb      8:16   0 149,1G  0 disk                                                
└─sdb1   8:17   0   149G  0 part                                                crypto_LUKS
sdc      8:32   0 465,8G  0 disk                                                
└─sdc1   8:33   0 465,8G  0 part                                                crypto_LUKS
sdd      8:48   0 298,1G  0 disk                                                
├─sdd1   8:49   0   512M  0 part                                                vfat
├─sdd2   8:50   0 295,6G  0 part /media/bc/a501872f-9564-4568-a942-8b913bb93166 btrfs
└─sdd3   8:51   0     2G  0 part

my open suse tumbleweed laptop harddrive is sdd, extra info: sdb and sdc is my data hardrive it's different physical hardrive

Update from chat: target filesystem is btfrs, lines in former /etc/fstab are

UUID=a501872f-9564-4568-a942-8b913bb93166 / btrfs defaults 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /home btrfs subvol=/@/home 0 0

what is needed is a command line to mount home subvolume.

Improve this question
10
  • 1
    can you show us lsblk output ? Commented May 16, 2023 at 6:55
  • @admstg lsblk added Commented May 16, 2023 at 7:21
  • @Archemar on my desktop pc(ubuntu) I do sudo su then lsblk then vgscan /dev/sdd then it return Command does not accept argument: /dev/sdd. Commented May 16, 2023 at 7:30
  • I would mount /dev/sdd2 manually as root and try to access the data as root from the mount point, the automatic mount isn't reliable in this case. Commented May 16, 2023 at 7:45
  • 2
    lsblk -o +fstype | grep -v /snap/ would filter out the snaps (which are not relevant in this situation) and also identify filesystem type of each partition, which would have been more useful than plain lsblk. Commented May 16, 2023 at 7:48

1 Answer 1

Reset to default
4

Here's your /etc/fstab recovered from /dev/sdd2 (from chat):

UUID=a501872f-9564-4568-a942-8b913bb93166 / btrfs defaults 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /var btrfs subvol=/@/var 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /srv btrfs subvol=/@/srv 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /root btrfs subvol=/@/root 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /opt btrfs subvol=/@/opt 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /home btrfs subvol=/@/home 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=a501872f-9564-4568-a942-8b913bb93166 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=DDC0-DAF7 /boot/efi vfat utf8 0 2
UUID=a501872f-9564-4568-a942-8b913bb93166 /.snapshots btrfs subvol=/@/.snapshots 0 0

Your system was set up to use btrfs subvolumes. This is the usual configuration for a modern OpenSuSE.

As the main btrfs volume of /dev/sdd2 is already mounted at /media/bc/a501872f-9564-4568-a942-8b913bb93166, you should be able to mount the "missing" parts with:

export MOUNTPATH=/media/bc/a501872f-9564-4568-a942-8b913bb93166
sudo mount -o subvol=/@/var /dev/sdd2 $MOUNTPATH/var
sudo mount -o subvol=/@/usr/local /dev/sdd2 $MOUNTPATH/usr/local
sudo mount -o subvol=/@/srv /dev/sdd2 $MOUNTPATH/srv
sudo mount -o subvol=/@/root /dev/sdd2 $MOUNTPATH/root
sudo mount -o subvol=/@/opt /dev/sdd2 $MOUNTPATH/opt
sudo mount -o subvol=/@/home /dev/sdd2 $MOUNTPATH/home

The above is a straightforward conversion from your /etc/fstab to the recovery situation, with the $MOUNTPATH variable defined to save some typing effort and to make the lines easier to read and understand.

In btrfs, the subvolumes are somewhat like LVM logical volumes: they all share the same physical space, so you won't have the "my free space is in the wrong filesystem" problem that is common to traditional setups with multiple filesystems, no LVM and less-than-absolutely-perfect advance planning.

Here, the subvolumes must be mounted like separate filesystems because SuSE sets them up that way by default. It's also possible to let the filesystem handle the subvolumes so that they'd get mounted automatically along with the "main" volume (aka the default subvolume).

When mounting a btrfs filesystem, if you don't specify the subvol= mount option, the filesystem driver will assume you meant the default subvolume. Unless the filesystem is specifically configured otherwise, the default subvolume will be subvol=/.

If you hadn't been able to get the /etc/fstab file from the root filesystem (= the btrfs main volume in this case), you could find out the existence and names of any non-default subvolumes with sudo btrfs subvolume list -a <mountpoint of the btrfs filesystem>.

Improve this answer
5
  • I'm curious more about the missing parts, how did you identified it, did this missing parts cause me to cannot access my data even though it is already mounted? Commented May 16, 2023 at 8:23
  • I think I kinda understand, the mount is somewhat like not finished and your command is help my desktop pc to link the folder with the correct path, I have some adaptation to the command that you send. in open suse tumbleweed (currently that I use) the path of mounted hard drive is on /run/media/username/uuid instead /media/username/uuid like on ubuntu I could access my data now Commented May 16, 2023 at 8:29
  • 2
    In btrfs, the subvolumes are somewhat like LVM logical volumes: together with the main volume, they share the physical space (so you won't have the "my free space is in the wrong filesystem" problem that is common to traditional setups with no LVM and multiple filesystems) but they must be mounted like separate filesystems. Commented May 16, 2023 at 8:29
  • 2
    Having to "mount" the subvolumes separately is purely due to openSUSE setting them up like that by default. In general, btrfs subvolumes are ordinary directories which can be attached anywhere in the directory hierarchy, so you can have /home and /var subvolumes under the / subvolume and mount everything in one go by mounting /. However, openSUSE chose to hide all these subvolumes from plain sight by putting them under /@/ so you have to bind mount them to the right places explicitly. Commented May 16, 2023 at 15:14
  • @TooTea Thanks for clarification; so far I've encountered btrfs only on SuSE systems, so their way of setting it up is the one I'm familiar with. Commented May 16, 2023 at 15:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.