SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Whenever I plug in an luks encrypted USB device, Thunar recognises it, prompts me for the password, but fails to mount with the error:
"not authorized to perform operation"
Non-encrypted usb drives work fine. I installed the current mate desktop via MSB and Caja has the same behavior so I'm thinking that this is not a specific issue with Thunar or Caja. On a Ubuntu system will decrypt and mount the same drives without issue (Thunar or Caja).
I've done a bit of searching but cannot seem to find a resolution to this issue.
Same behavior, two different systems both running Slack64 15 with all updates applied.
need to see the logs. Probably something is missing (a software/package/config??) on that host.
Both hosts are a nearly full install (no KDE packages, but all of the disksets: a, ap, d, e, f, k, l, t, tcl, x, xfce, y) with a few totally unrelated packages excluded from xap and n. I attempted to mount an encrypted disk and checked the logs. I didn't see anything relevant. Nothing related followed in the logs other than the events from physically disconnecting the USB drive.
dmesg -T
Quote:
[Tue Mar 21 17:42:06 2023] scsi 6:0:0:0: Direct-Access Seagate BUP Slim Mac
SL 0304 PQ: 0 ANSI: 6
[Tue Mar 21 17:42:06 2023] sd 6:0:0:0: [sdb] Spinning up disk...
[Tue Mar 21 17:42:07 2023] .....ready
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] 3907029167 512-byte logical blocks:
(2.00 TB/1.82 TiB)
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] 2048-byte physical blocks
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] Write Protect is off
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: e
nabled, doesn't support DPO or FUA
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] Optimal transfer size 33553920 byte
s not a multiple of physical block size (2048 bytes)
[Tue Mar 21 17:42:11 2023] sd 6:0:0:0: [sdb] Attached SCSI disk
/var/log/messages:
Quote:
Mar 21 17:42:07 slacktop kernel: usb 2-2: new SuperSpeed USB device number 6 usi
ng xhci_hcd
Mar 21 17:42:07 slacktop kernel: usb 2-2: New USB device found, idVendor=0bc2, i
dProduct=ab25, bcdDevice= 1.00
Mar 21 17:42:07 slacktop kernel: usb 2-2: New USB device strings: Mfr=2, Product
=3, SerialNumber=1
Mar 21 17:42:07 slacktop kernel: usb 2-2: Product: BUP Slim Mac SL
Mar 21 17:42:07 slacktop kernel: usb 2-2: Manufacturer: Seagate
Mar 21 17:42:07 slacktop kernel: usb 2-2: SerialNumber: NA9J0S6F
Mar 21 17:42:07 slacktop kernel: scsi host6: uas
Mar 21 17:42:07 slacktop kernel: scsi 6:0:0:0: Direct-Access Seagate BUP Sl
im Mac SL 0304 PQ: 0 ANSI: 6
Mar 21 17:42:07 slacktop kernel: sd 6:0:0:0: [sdb] Spinning up disk...
Mar 21 17:42:07 slacktop mtp-probe: checking bus 2, device 6: "/sys/devices/pci0
000:00/0000:00:14.0/usb2/2-2"
Mar 21 17:42:07 slacktop mtp-probe: bus: 2, device: 6 was not an MTP device
Mar 21 17:42:12 slacktop kernel: sd 6:0:0:0: [sdb] 3907029167 512-byte logical b
locks: (2.00 TB/1.82 TiB)
Mar 21 17:42:12 slacktop kernel: sd 6:0:0:0: [sdb] 2048-byte physical blocks
Mar 21 17:42:12 slacktop kernel: sd 6:0:0:0: [sdb] Write Protect is off
Mar 21 17:42:12 slacktop kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read ca
che: enabled, doesn't support DPO or FUA
Mar 21 17:42:12 slacktop kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
Are you having a permissions problem? Did you encrypt as root and try to decrypt as user?
No file permissions issues. If I do the cryptsetup luksOpen on the device and manually mount the drive as root, the regular user account can access the contents of the drive. The UIDs are correct allowing rw to the entire filesystem by the non-root account(s).
Quote:
Originally Posted by jailbait
Is the password that Thunar is asking for the root password or the encryption password?
It is asking for the drive's encryption password, as expected. The error is about not being able to mount
Code:
"Unable to mount 2.0 TB Encrypted"
"Not authorized to perform operation"
Again, the same drive mounts fine on a Ubuntu host via Thunar once given the correct password for the luks encryption.
Just a follow up after doing a little more digging on this. I've verified that libblockdev does have crypto support and that udisk2 is properly configured for luks support.
Running `udiskctl` to unlock and mount the drive works fine, so the underlying systems are working properly. It seems that the desktop filemanagers are not handing things off with the appropriate level of permissions to actually mount the unlocked device.
Could it be that you as a normal user have read and write permission to /dev/sdX? Where sdX? are partitions of USB storage but lack read or write permission to /dev/loop*?
Whenever I plug in an luks encrypted USB device, Thunar recognises it, prompts me for the password, but fails to mount with the error:
"not authorized to perform operation"
Non-encrypted usb drives work fine. I installed the current mate desktop via MSB and Caja has the same behavior so I'm thinking that this is not a specific issue with Thunar or Caja. On a Ubuntu system will decrypt and mount the same drives without issue (Thunar or Caja).
I've done a bit of searching but cannot seem to find a resolution to this issue.
Same behavior, two different systems both running Slack64 15 with all updates applied.
Hmm, I've seen this one before, and it was solved. I think even here on this very forum there was a guy with a similar issue. Let's see if I can remember...
This has to do with polkit permissions, since the operation in question is done through the GUI (but is normally a root operation if done manually). Which means the correct kind of access to do this through the GUI is granted ONLY if the correct set of polkit actions are specified (and exist).
There should be enough information in there to solve the issue. But if you need further help with it, I could perhaps go through it again (it's a good refresh for me as well).
All in all, it could potentially be as easy as adding "plugdev" group to your user..
This has to do with polkit permissions, since the operation in question is done through the GUI (but is normally a root operation if done manually). Which means the correct kind of access to do this through the GUI is granted ONLY if the correct set of polkit actions are specified (and exist).
All in all, it could potentially be as easy as adding "plugdev" group to your user..
That was a good dive into polkit rules. So far, it has not resolved the issue by adding polkit rules as the thread suggested. However, it does seems like the right direction.
Additional data points:
1. As mentioned before, encrypted drives will not mount after providing the password but unencrypted drives work fine.
2. The desktop is also not able to mount/browse MTP devices (Android) via the GUI.
3. All of the above works fine when logged in as root, so it's definitely some issue with escalation of privileges in the desktop environment.
4. The non-root users are members of all the recommended groups (users, lp, wheel, floppy, plugdev, audio, cdrom, input, power, netdev, scanner)
I've been using Slackware for almost 30 years and this has been one of the most weird/difficult issues I've run into. I guess it's time to dig deeper into the desktop environment.
So, in desperation, I decided to install the "kde" disk set onto the system. The luks encrypted drive properly mounts in Dolphin as well as MTP devices. Not only that, but now Thunar and Caja can also handle these devices. Now I need to figure out what the KDE packages are providing that the other desktop environments are missing.
So, in desperation, I decided to install the "kde" disk set onto the system. The luks encrypted drive properly mounts in Dolphin as well as MTP devices. Not only that, but now Thunar and Caja can also handle these devices. Now I need to figure out what the KDE packages are providing that the other desktop environments are missing.
Smaller desktop environments often use some components of other desktop environments (gtk etc etc). For Slackware, that means that a component that might be used by XFCE(??) is classified as a KDE component instead, ergo, is in the KDE packages. As you probably seen in that thread polkit actions for KDE is controlled by something called "kauth", perhaps XFCE also use that. That's kinda just rephrasing what you said, but say it does use kauth, anything you did with polkit earlier would have no effect without it.
Otherwise, the method of elimination could work well. Reading every KDE package description and removing them one by one, except the ones you might think could be related. Once you end up with a smaller set (and the function still works), you could do the same again. (it's all on the dvd/usb)
Smaller desktop environments often use some components of other desktop environments (gtk etc etc). For Slackware, that means that a component that might be used by XFCE(??) is classified as a KDE component instead, ergo, is in the KDE packages. As you probably seen in that thread polkit actions for KDE is controlled by something called "kauth", perhaps XFCE also use that. That's kinda just rephrasing what you said, but say it does use kauth, anything you did with polkit earlier would have no effect without it.
IIRC, XFCE had a setting for starting the KDE and GNOME settings daemons. Try disabling loading the KDE daemon, and see if the functionality still works. If it doesn't work, you need KDED and it's dependencies. If it does work, then there's another dbus package that's doing the work.
Thunar and Caja now work (because possibly) KDED is doing all of the work through dbus, polkit and udisks, and KDED knows what to do. So you just need to find that missing link that communicates with dbus to get this working.
So, in desperation, I decided to install the "kde" disk set onto the system. The luks encrypted drive properly mounts in Dolphin as well as MTP devices. Not only that, but now Thunar and Caja can also handle these devices. Now I need to figure out what the KDE packages are providing that the other desktop environments are missing.
As another user opting out of kde, I ran into the same problem. My luks-encrypted data-drives were mainly for backup and I wanted them to become part of the file system with a unique mounting point. For this, I have a script (named after the mount point) for each drive that combines the relevant luks-commands, for example:
Code:
# !/bin/bash
# steps to mount external DATA_ANALYSIS_4 drive
#
# /usr/local/sbin/DATA_ANALYSIS_4.sh
#
# start/stop
case "$1" in
'start')
#cryptsetup luksOpen /dev/sdc1 lukssdc1
cryptsetup luksOpen UUID="3b76d01f-7aae-4385-8260-0b1445aefddf" lukssdc1
lvchange -a y 4Tvg
mount /dev/4Tvg/working_4Tb
;;
'stop')
umount /home/working/DATA_ANALYSIS_4
lvchange -a n 4Tvg
cryptsetup close lukssdc1
;;
'fail-stop')
pvdisplay
#dmsetup info -C
vgchange -a n 4Tvg
cryptsetup close 4Tvg
;;
*)
echo "Usage: $0 {start|stop|fail-stop}"
;;
esac
Of course this is not the sought for solution (still depends on root access to run the script). Good luck with identifying the kde-dependency; maybe it leads to a workaround or only the install of a single module.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.