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.
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.
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
(It’s getting late here and my mind is shuting down, so excuse me if i start to say nonsense)
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:
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.
Then please mark the solution to close this topic, because the title is solved
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.
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.
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)
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)
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”
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…
