Unable to mount encrypted USB hard drive

Running KDE Manjaro with the latest updates.

I have used an encrypted USB hard drive several times.

Today, when I tried mounting it, it showed the notification of an USB drive plugged in. When I chose ‘Mount and Open’ it asked for a password like it always did.

On entering the correct password, it produces an error ‘Could not mount this device’.

On entering an incorrect password. it produces the same error.

Other USB hard drives mount properly. This USB hard drives mounts properly on other computers.

How do I set things right?

Are they all running the same operating system and language?

@TriMoon Thanks.

Yes. The other computer is also running KDE Manjaro. But it is not updated with the latest updates.

I can not reproduce this issue after the latest update (Testing branch). I use 3 different USB hard drives, each USB hard drive uses LUKS encryption and different Linux filesystem. All are mounted without issue.

Maybe you created the encryption using different options that need some cipher etc that’s not available on the machine you’re unable to mount at?

How you should/could check the difference between that HD’s encryption and the other HD’s goes above my knowledge though :woman_shrugging:

Maybe this manpage could help in viewing debug info:

man cryptsetup-luksOpen

–debug or --debug-json
Run in debug mode with full diagnostic logs. Debug output lines are always prefixed by #.

       If --debug-json is used, additional LUKS2 JSON data structures are printed.
1 Like

On a related note, the other computer where the drive opens without any problem is running cryptsetup v2.4.

The computer where the drive can not open has cryptsetup v2.5. But I had used the same drive on this computer earlier without any error.

encryption uses cryptography so uhmm…maybe compare the versions of openssl installed?
I remember ppl having problems with that package recently, not sure if that is also used by cryptsetup but who knows :woman_shrugging:

(It’s getting late here and my mind is shuting down, so excuse me if i start to say nonsense)

Try what @TriMoon suggested. Bypass KDE’s handling of external drives for now and simply try to unlock the container manually using cryptsetup.

The error message from KDE might be a red herring.

1 Like

@TriMoon @winnie Thanks.

So, I tried opening the container from the command line. Here is the output of the command when run as a normal user:

# cryptsetup 2.5.0 processing "cryptsetup --debug open /dev/sdb1 tempfold"
# Verifying parameters for command open.
# Running command open.
# Locking memory.
# Cannot lock memory with mlockall.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/sdb1.
# Trying to open and read device /dev/sdb1 with direct-io.
# Trying to open device /dev/sdb1 without direct-io.
Device /dev/sdb1 does not exist or access denied.
Command failed with code -4 (wrong device or file specified).

When I run the command with a sudo like sudo cryptsetup --debug open /dev/sdb1 tempfold here is the output:

# cryptsetup 2.5.0 processing "cryptsetup --debug open /dev/sdb1 tempfold"
# Verifying parameters for command open.
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/sdb1.
# Trying to open and read device /dev/sdb1 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/sdb1.
# Crypto backend (OpenSSL 3.0.7 1 Nov 2022 [default][legacy]) initialized in cryptsetup library version 2.5.0.
# Detected kernel Linux 5.15.78-1-MANJARO x86_64.
# PBKDF pbkdf2-sha256, time_ms 2000 (iterations 0).
# Reading LUKS header of size 1024 from device /dev/sdb1
# Key length 32, device size 976705536 sectors, header size 2050 sectors.
# Activating volume tempfold using token (any type) -1.
# Interactive passphrase entry requested.
Enter passphrase for /dev/sdb1:

If I enter an incorrect key, it complains. On entering the correct key, it produces:

# Activating volume tempfold [keyslot -1] using passphrase.
# dm versions   [ opencount flush ]   [16384] (*1)
# dm status tempfold  [ opencount noflush ]   [16384] (*1)
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Reusing open ro fd on device /dev/sdb1
# dm versions   [ opencount flush ]   [16384] (*1)
# dm status tempfold  [ opencount noflush ]   [16384] (*1)
# Calculated device size is 976701440 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-3a2bf693471b4309adc5ddf3103a1594-tempfold
# Udev cookie 0xd4d82c1 (semid 16) created
# Udev cookie 0xd4d82c1 (semid 16) incremented to 1
# Udev cookie 0xd4d82c1 (semid 16) incremented to 2
# Udev cookie 0xd4d82c1 (semid 16) assigned to CREATE task(0) with flags DISABLE_LIBRARY_FALLBACK         (0x20)
# dm create tempfold CRYPT-LUKS1-3a2bf693471b4309adc5ddf3103a1594-tempfold [ opencount flush ]   [16384] (*1)
# dm reload   (254:1) [ opencount flush securedata ]   [16384] (*1)
# dm resume tempfold  [ opencount flush securedata ]   [16384] (*1)
# tempfold: Stacking NODE_ADD (254,1) 0:0 0600 [trust_udev]
# tempfold: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d82c1 (semid 16) decremented to 1
# Udev cookie 0xd4d82c1 (semid 16) waiting for zero
# Udev cookie 0xd4d82c1 (semid 16) destroyed
# tempfold: Skipping NODE_ADD (254,1) 0:0 0600 [trust_udev]
# tempfold: Processing NODE_READ_AHEAD 256 (flags=1)
# tempfold (254:1): read ahead is 256
# tempfold: retaining kernel read ahead of 256 (requested 256)
Key slot 0 unlocked.
# Releasing crypt device /dev/sdb1 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sdb1.
# Unlocking memory.
Command successful.

Hope this is helpful.

How do I set things right?

Well ok so you are able to open the LUKS1 encrypted container on this machine after-all, so it’s not an issue of missing ciphers etc…

It is perfectly normal that you need root privileges to access device partitions.

Now lets try to mount the filesystem inside that encrypted container, because that is where the real data is…

sudo cryptsetup close tempfold
sudo cryptsetup open /dev/sdb1 tempfold
systemd-mount /dev/mapper/tempfold /media/encrypted_hdpartition
sudo ls -la /media/encrypted_hdpartition
  • The first line is just to close the container in case you still had it open…
  • If all goes well you should see the directories/files inside…
    You still need root privileges to access that /media/encrypted_hdpartition mount point though, thats why the sudo on last line.
  • To unmount you need to issue systemd-umount /media/encrypted_hdpartition followed by closing the container as in the 1st line.

Why it doesn’t work using the KDE-GUI is beyond my knowledge level. :woman_shrugging:

1 Like

@TriMoon Thanks.

All went well. I could browse the files on the encrypted drive.

But, alas, KDE GUI still does not allow me to mount the hard disk.

Then please mark the solution to close this topic, because the title is solved :slight_smile:
Then create a new topic specifically for the KDE-GUI mounting that does not work in this use-case, referring to this topic so others with more knowledge about that part will notice it and can assist more.


Just one more question.
Is there a way by which using the command line, I can access the partition? From the terminal? As a normal user?

Any filesystem on any partition that gets mounted is normally only available to the root user, unless the permissions on that filesystem allow a normal user to access them.
It’s normal Unix behavior. :woman_shrugging:

You could override it, eg give extra permissions, using setfacl on the mount-point after mounting the filesystem if that filesystem supports extended attributes…

But you would still need root to mount the filesystem and encrypted container ofcourse… (Unless im mistaken)

OK. Got that. But when I connect an unencrypted drive, I can access it as a normal user. Can I mimic that behavior for the encrypted drive?

So, I will mount the drive as root. And then, kind of, pass it on to the user.

So, this command wont need a sudo. :slight_smile:

Like i said above, that sudo is needed because the files/directories inside the filesystem are normally accessible by root only due to file permissions.
(Unless given extra permission overrides using setfacl)

Just to make this topic ‘complete’, here is the command I used to grant access to a normal user:

setfacl -m u:user:rwx /run/media/user/encrypted-partition

Using -R -m u:user:rwX,d:u:user:rwX ... would be more appropriate to apply it to all sub-dirs and files, i “think” :smile_cat:

  • Using captial X instead of lowercase is so it doesn’t force the execute bit on files/dirs that don’t already have it…
  • The d:u:user:rwX part makes sure new ones get created using those extra permissions also…
  • One could as an alternative, to be more system-agnostic, use o:rwX,d:o:rwX instead, so it isn’t bound to user-id on current system.
    Which makes it equal to “world read/writable” so be sure you want that…

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.