Problems with mounting new disc via LUKS/BTRFS

Support
1

Hello all!

I bought a “Western Digital Ultrastar DC HC560 20TB” (identical in construction: “Western Digital WD Gold 20TB”).

The following problem: I can not mount it (automatically) via LUKS/BTRFS.

Several tried scenarios I mention here, because I tried a lot and also repeated several times and sometimes different results came out:

  1. Formatted via Disks (Gnome): Formatted a LUKS2 encryption which releases a BTRFS partition.

Option a.) Subsequently, the partiation can not be mounted, it comes:

Error mounting filesystem [...] wrong fs type, bad option, bad superblock on /dev/mapper/luks[...] missing codepage or helper prog or other error (udisk-error-quark, 0)

Option b.) I also got the partition mounted once, but only via Gnome Disk (dont know why).

But either way the mount with crypttab/fstab entry was not possible, tried several times. Result:

Failed to mount /xyz/
Dependency failed for local system

See the screenshots for this.

  1. Formatted via KDE partition manager, where LUKS1+BTRFS is used. Here the same problem. Whereas here I had no problem to mount it via the frontend of the KDE partition manager the harddisk. But via the crypttab/fstab entry it doesn’t work here either.

For info:

I have never had such a problem over the last 3 years and have mounted multiple disks this way with no problems. I think I know what I am doing. But maybe I am overlooking this a bit?

I have tried mounting/unmounting the drive both via SATA, and via a SATA-to-USB adapter. Tried everything several times. I have also searched the net looking for my problem and honestly I despair :frowning:

What’s important is that the first disk I got delivered was faulty, it wouldn’t spin up. Got a new one. Is there possibly massive quality issues there? Is that the problem? I don’t think so, what do you think?

Worth mentioning maybe that the hard drive caches some of its track information on a mini SSD, 64GB I think. But that should clear up the firmware, that shouldn’t affect the user hardware layer I think.

What I also found funny, I copied another working LUKS/BTRFS disc so such via “dd /sdFUNKTIONIERD to /sdNEU”, this resulted in very low transfer rates ~10MB/s and the HDD kept falling asleep and spinning up again. This went on for 30 minutes until I canceled it. Did not understand why?

Calling a “dmesg” results in:

[36206.709806] BTRFS info (device dm-8): flagging fs with big metadata feature
[36206.709812] BTRFS info (device dm-8): enabling disk space caching
[36206.709813] BTRFS error (device dm-8): cannot disable free space tree
[36206.709833] BTRFS error (device dm-8): open_ctree failed

Here attempt to check the “broken” BTRFS partition for errors:

sudo btrfs check /dev/mapper/luks-458323f0-18a4-4928-b01d-27e02d06f2e8

Opening filesystem to check...
Checking filesystem on /dev/mapper/luks-458323f0-18a4-4928-b01d-27e02d06f2e8
UUID: 2575c981-8112-497b-8a24-ee2f9850ce29
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 147456 bytes used, no error found
total csum bytes: 0
total tree bytes: 147456
total fs tree bytes: 32768
total extent tree bytes: 16384
btree space waste bytes: 139609
file data blocks allocated: 0
 referenced 0

I checked the partition in the KDE partition manager via right click/check:

Check and repair partition "/dev/sde1" (18,19 TiB, Btrfs) 
Operation: The file system on partition "/dev/sde1" is checked. 
Command: btrfs check --repair /dev/mapper/luks-458323f0-18a4-4928-b01d-27e02d06f2e8 
The file system on the partition "/dev/sde1" is checked: Successful

Operation: File system on "/dev/sde1" is maximized so that it fills the partition. 
The file system on partition "/dev/sde1" already has the desired length of 39,063,646,208 sectors. 
File system on "/dev/sde1" is maximized so that it fills the partition: Successful
Check and repair partition "/dev/sde1" (18.19 TiB, Btrfs): Successful

Thanks for reading this, maybe someone has an idea! :slight_smile:

PS: I posted this topic on the German board, but since there were hardly any responses, I escalated this topic here. [Probleme mit Einbinden neuer Disk per LUKS/BTRFS - Manjaro-Linux-Forum]

2

What does your crypttab and fstab look like…?

That’s kind of important.

1 Like
3

fstab:
/dev/mapper/luks-458323f0-18a4-4928-b01d-27e02d06f2e8 /mnt/v2_20TB btrfs defaults,noatime,space_cache 0 2

crypttab:
luks-458323f0-18a4-4928-b01d-27e02d06f2e8 UUID=458323f0-18a4-4928-b01d-27e02d06f2e8 /crypto_keyfile.bin luks

4

Hm… you could also use this section for german: Deutsch

5

@Humbi But you can open it on the terminal right?

cryptsetup open /dev/sdXY hdd --type luks

sudo mount -m -t btrfs /dev/mapper/hdd /media/hdd

Exist this the folder?

Maybe add X-mount.mkdir=755 to the options at fstab, so that it creates the folder automatically if not existed.

6

That’s usually the keyfile used to unlock the root partition. Did you use a keyfile or passphrase when you created this LUKS container (for the default keyslot)?

7

The folder “/mnt/v2_20TB” exists already, double-checked it.

The LUKS container is already opened, see screenshot.

I also tried in Gnome Disk to format a new BTRFS disk inside the LUKS container, but it doesnt help.

8

I added this keyfile to this LUKS container using “sudo cryptsetup luksAddKey --key-slot 4 /dev/sde1 /crypto_keyfile.bin”

That’s usually the keyfile used to unlock the root partition. Did you use a keyfile or passphrase when you created this LUKS container (for the default keyslot)?

I created the partition using a passphrase and later on added more passphrases and this keyslot. As told before, I did this on several disks before the last years, never had problems like this. Dont know the reason.

9

Try adding this to your crypttab entry:

key-slot=4

So it might look like this:

luks-458323f0-18a4-4928-b01d-27e02d06f2e8 UUID=458323f0-18a4-4928-b01d-27e02d06f2e8 /crypto_keyfile.bin luks,key-slot=4

But it still shouldn’t matter, as long as the keyfile works on any keyslot.

10

The LUKS decrypt is no problem, as it is already mounted. But why BTFS makes problemes here?

11

Let’s go back to this. One step at a time. :point_up:

Close/lock everything.

Then only unlock the LUKS container with a specific name:

cryptsetup open /dev/sde1 crypto_test --type luks --key-file=/crypto_keyfile.bin

And check under /dev/mapper/

ls -l /dev/mapper/

We’ll continue from here…

1 Like
12

It didn’t before.

This is from your earlier post:

Everything is normal.

1 Like
13

I just realized, you didn’t specify a subvolume in your fstab. :person_facepalming:

Did you create any subvolumes? Is it meant to be just one giant root subvolume?

Nevermind. See below. (Suspected something was off about the keyfile usage.)

Nevermind again. They forgot to use sudo. :laughing:

14

OK. Dismounted the LUKS container.

$ cryptsetup open /dev/sde1 crypto_test --type luks --key-file=/crypto_keyfile.bin
Gerät »/dev/sde1« does not exist or access denied.

$ ls -l /dev/mapper/

gives a lot of output, but not the disk

15

You need to use sudo

1 Like
16

yes, now it is after:

$ ls -l /dev/mapper/

lrwxrwxrwx 1 root root 7 29. Mai 00:06 crypto_test → …/dm-8

17

Okay, now try to mount that.

sudo mkdir -p /mnt/btrfs_test

sudo mount -t btrfs /dev/mapper/crypto_test /mnt/btrfs_test -o defaults,noatime,space_cache
18 
$ sudo mount -t btrfs /dev/mapper/crypto_test /mnt/btrfs_test -o defaults,noatime,space_cache
mount: /mnt/btrfs_test: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/mapper/crypto_test ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
       dmesg(1) könnte nach einem fehlgeschlagenen mount-Systemaufruf
       weitere Informationen liefern.

same error, as before (sry in german)

19

Try again, without any options:

sudo mount -t btrfs /dev/mapper/crypto_test /mnt/btrfs_test
1 Like
20

wow… it works!!!