Trouble automounting a LUKS parition that is on a mdadm raid6 (lemmy.world)

submitted 3 weeks ago* (last edited 3 weeks ago) by Hercules@lemmy.world to c/selfhosted@lemmy.world

14 comments fedilink hide all child comments

Hi fellow selfhoster,

Im a bit lost on the following scenario and im unable to find any documentation about it so i was hoping some smart people here could point me in the right direction.

I have a linux software raid 6 that contains a LUKS partition with ext4 in it. I would like to automount the ext4 when im rebooting. The root partition is also using LUKS and i have successfully setup the decryption for this parition but im uncertain on how to do this with this raid setup since im not sure where in the boot process linux recognizes my raid and when the decryption happens.

This is what i have:

[root@nfs-rocky-1 ~]# cat /etc/mdadm.conf
ARRAY /dev/md/server1:0 metadata=1.2 UUID=3e198408:2236ed3d:1dc13a8e:e5f91e52

On a reboot the raid does get automaticly recognizes but i still have to do cryptsetup luksOpen /dev/md0 raid & mount /dev/mapper/raid /mnt/data.

What would be the best way to do this? Im a bit scared of doing this im not certain of since i don't want my machine to be stuck at a boot.

Just a like to an article that dicusses something like this already would help me greatly.

you are viewing a single comment's thread
view the rest of the comments

[-] db_geek@norden.social 5 points 3 weeks ago* (last edited 3 weeks ago)

@Hercules I have a similar setup with RAID1 and BTRFS.
I'm using a keyfile for that:
dd bs=512 count=4 if=/dev/random of=/etc/crypttab.d/keyfile-data.bin iflag=fullblock
chmod 600 /etc/crypttab.d/keyfile-data.bin

cryptsetup luksAddKey /dev/mapper/raid /etc/crypttab.d/keyfile-data.bin --new-key-slot 1

entry in /etc/crypttab:
data UUID=<blkid from /dev/md0> /etc/crypttab.d/keyfile-data.bin luks

entry in /etc/fstab:
UUID=<blkid from /dev/mapper/raid> /mnt/data .....

[-] db_geek@norden.social 2 points 3 weeks ago

Another way can be pam_mount, which I'm using on an SBC for opening an encrypted device:
https://inai.de/projects/pam/_mount/

[-] Hercules@lemmy.world 1 points 3 weeks ago

:D while your steps were very clear i think i fked up.

cryptsetup luksAddKey /dev/mapper/raid /etc/crypttab.d/keyfile-data.bin --new-key-slot 1 gave: Device /dev/mapper/raid is not a valid LUKS device.. I assume this is a typo from your end since /dev/md0 is my luks volume. But altering this gave me: slot is already in use kind of error.

That can be explained since i tested something simular like you suggested earlier. Afterwhich i removed my key i generated and added to the volume. Then i did cryptsetup luksRemoveKey /dev/md0.

Now when i try to add it i get No key available with this passphrase.

I don't have enough knowledge about cryptsetup to know what excactly i did wrong.

Do you by any change have an explaination?

In case this is usefull:

[root@nfs-rocky-1 ~]# cryptsetup luksDump /dev/md0
LUKS header information
Version:       	2
Epoch:         	6
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	485df758-6cec-49e3-aceb-438aaaedc833
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 4096 [bytes]

Keyslots:
  1: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       17 c5 ff 7f b9 10 43 41 16 5a c8 28 44 b9 df 64
	            a8 1d 40 41 9f a1 70 85 34 06 52 8d ba 29 bd ef
	AF stripes: 4000
	AF hash:    sha256
	Area offset:290816 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  2: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  12
	Memory:     1048576
	Threads:    4
	Salt:       64 97 db 49 f1 18 b9 57 3b 02 53 37 b3 11 8e 44
	            71 d1 70 b2 b9 58 4c db e2 6b 36 95 7c dd d2 be
	AF stripes: 4000
	AF hash:    sha256
	Area offset:548864 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 105703
	Salt:       ae ac f1 9f df 47 27 9e 64 28 52 53 9a 9b cd 77
	            74 15 66 f6 8b 3c bd f4 29 dc f1 b1 c5 15 3b f6
	Digest:     07 5f 2f 6b d3 c5 bf b6 54 58 5e b4 44 df 8c b8
	            2b da fa 5c 40 a5 89 cc 0e 3b 70 69 57 d5 7c f5
[root@nfs-rocky-1 ~]#

[-] db_geek@norden.social 2 points 3 weeks ago

@Hercules My exampled assumed, that you only have a password set on keyslot 0.

LUKS keyslots are starting at 0, so it seems, that you deleted the initial set password.
I hope, you know the other keyslots.

As far I can see, you can specify, which keyslot has to be selected for unlocking the volume key.
More information you can find in the man page.

man cryptsetup-luksaddkey

cryptsetup luksAddKey /dev/md0 --new-key-slot 0 --key-slot 1

[-] Hercules@lemmy.world 2 points 3 weeks ago

Just to give you an update. The other keyslot was the key i added earlier for testing which i removed ... So its time for me to copy over a lot of data to another system en recreate the luks volume. Thanks for your help!

[-] db_geek@norden.social 1 points 3 weeks ago

@Hercules So it was possible to use one of the other keyslots to open the encryption?

Probably you can test your wanted configuration in a virtual machine with some small virtual drives to avoid any loss of data.
I found it relative difficult to find the correct UUID which had to be used when I setup my system in the past.

[-] Hercules@lemmy.world 1 points 3 weeks ago

So it was possible to use one of the other keyslots to open the encryption?

No it wasn't. Luckely the luks parition was still mounted on my system so im making a backup, recreating the partiiton and the restoring ...

I found an article from RedHat on how to restore a luks1 partitions keys while it is still mounted but this isn't possible with luks2 :/

[-] db_geek@norden.social 2 points 3 weeks ago

@Hercules That was really luck. I hope, that your backup will be successful.

Until now I didn't used it, but probably I will also have a deeper look into luksHeaderBackup.

https://man.archlinux.org/man/cryptsetup-luksHeaderBackup.8.en
https://man.archlinux.org/man/cryptsetup-luksHeaderRestore.8.en

[-] Hercules@lemmy.world 1 points 3 weeks ago

Thanks for your response!

I will give it a try. Have a great rest of your day!

[-] Hercules@lemmy.world 1 points 3 weeks ago* (last edited 3 weeks ago)

Is the /etc/crypttab.d path that you are using specificly chosen or can it be whatever? This path doesn't exists on my system and online i don't see any mentions of it.

[-] db_geek@norden.social 3 points 3 weeks ago

@Hercules I created it on my own, because I have some keys for other devices, too.
But you can place it, where you want.
But with crypttab.d I have a simple connection to crypttab configuration file.

[-] nublug@piefed.blahaj.zone 1 points 3 weeks ago

the crypttab.d thing is called a drop-in directory. linux will read files you make in these and overwrite the config files with the values in the drop-in files. it's a way to add your own edits to config files without editing the default config files directly, so you don't have to say manually copy crypttab to crypttab.old for a backup and instead always have a default config to fall back to if things go wrong by just commenting out your few changes in the drop-in file.

this post was submitted on 21 Jun 2026

21 points (95.7% liked)

Selfhosted

60734 readers

243 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world