Problem with mounting encrypted drives

Desktop Environments Cinnamon
1

Hello everyone!

I have a problem with mounting drives that are encrypted. When I boot up the system not encrypted drives are mounted, but encrypted drives are not even though I choose the option to “remember password forever” (I don’t use English version of the system).

I boot my system, click on the encrypted drive, put in the password and click “remember the password” (the last option). It remembers the password until I close the system. If I log out it still remembers it but not after rebooting.

When I boot up my system again (and I do it 3-4 times everyday) the system doesn’t remember the password to the drive. So I click on the drive, put in the password and get a message that “there’s an error with keeping the passwords in the database and the name is not activatable” and the drive is not mounted immediately. I have to close the message by clicking OK, click again on the drive to mount it (without writing the password again), and then the drive is mounted.

I checked other drives that I have and it happens with every encrypted drive. I use Nemo and Wayland.

Do you have any idea how to solve this?

2

You can try “gnome-disk-utility”, it can be found in the repositories.

gnome-disk-utility
gnome-disk-utility990×690 64.8 KB

1 Like
3

First, see here (what I detail below is my own notes from this process):
See crypttab > Mounting at boot time.

You can generate a strong passphrase for each of these volumes, and have that stored in file and referenced by /etc/crypttab when mounting those volumes. The process is as follows:

  1. Generate random passphrase.
  2. Add that passphrase as a key to your LUKS volume.
  3. Reference your LUKS volume UUID.
  4. Add the LUKS volume to /etc/crypttab.
  5. Add the decrypted volume to /etc/fstab.

GUIDE:

1. Generate random passphrase.

This will generate a strong random passphrase, and store it under /root/lukskey .

sudo dd if=/dev/random bs=32 count=8 of=/root/lukskey

2. Add that passphrase as a key to your LUKS volume.

This won’t replace any existing passphrase, it will add an additional one. Replace somevolume with the actual volume in question :

sudo cryptsetup luksAddKey /dev/somevolume /root/lukskey

3. Reference your LUKS volume UUID.

To find the UUID of your LUKS volume:

lsblk --fs | grep LUKS

That should look something like this, with 01234567-0123-0123-0123-0123456789ab being the UUID in this example:

NAME FSTYPE FSVER LABEL UUID
├─nvme0n1p2 crypto_LUKS 1 01234567-0123-0123-0123-0123456789ab

Copy that UUID, you’ll need it in a moment.

4. Add the LUKS volume to /etc/crypttab.

Edit /etc/crypttab. Replace somelongUUID with the UUID referenced earlier :

# <name>				<device>			  <password>
luks-somelongUUID		UUID=somelongUUID     /root/lukskey luks

So using the example, that would look like:

luks-01234567-0123-0123-0123-0123456789ab UUID=01234567-0123-0123-0123-0123456789ab /root/lukskey luks

That will result in it getting mapped under /dev/mapper/luks-01234567-0123-0123-0123-0123456789ab.

5. Add the decrypted volume to /etc/fstab.

Now map the decrypted volume in /etc/fstab, replacing somelongUUID with the LUKS UUID referenced earlier, and /some/mountpoint with an actual mountpoint (like somewhere in your home folder), and the filesystem (btrfs) and options (compress=zstd,noatime) with your volumes correct filesystem and options:

/dev/mapper/luks-somelongUUID	/some/mountpoint	btrfs	compress=zstd,noatime	0 0

Really check over your configuration before rebooting. Incorrect settings in these files can result in an unbootable system. You might even cross-check this with other sources, to verify the process.

See crypttab > Mounting at boot time.

4

Hello, thank you for your reply. Unfortunately your solution doesn’t work, I still have to type the password after booting the system.

5

I’m a linux newbie. I won’t try your solution, sorry. I’m afraid I could destroy my drives and work data. Thanks for your help anyway.

1 Like
6

Not gonna lie, don’t know if it’s a KDE vs Cinnamon thing or an Ubuntu vs Arch thing, but I actually have the same issue you have.

On my Ubuntu Studio installation with KDE, the same encrypted partition auto-mounts after I select “remember password”. However, my Arch installation with Cinnamon/i3 does not auto-mount and each time I boot, I need to click on the drive to mount it.

I may try the solution above, but that’s a lot for a newbie, so I understand your reluctance.

I guess this is one of those examples where using the “newbie distro” is “better”. :person_shrugging:

7

I installed MX Linux, everything works out of the box but I’m not a fan as I don’t like xfce.
I tried Kubuntu, no problem with auto-mounting drives. It seems Debian related distros have no problem with auto-mounting drives.
I don’t feel confident enough to try to install pure Arch. I might try Manjaro though to check if it works.
I wonder why Firefox doesn’t work under Endeavour?? Speech synthetizer was not installed? Why not? Why customization settings don’t stick? After today update I lost Bluetooth functionality… Very strange.

8

Most Arch-based distro are DIY distros. This means that they usually only include what is necessary for running your system. You, as the user, need to add and enable anything extra that you want.

For Linux newbies, it is better for them to start with something Debian/Ubuntu-based and use it for a few years as a daily driver before trying out something Arch-based.

It is not that either one is actually “better” objectively, it’s just that one may be better for different groups of people.

As far as enabled-by-default features are concerned, Garuda (a gaming Arch-based distro) would likely have all the features a Linux newbie would expect by default. But, it is optimised to work with new gaming laptops/desktops, and may not support older PCs.

2 Likes