You are not logged in.
I found the reason, KDE has `Removable Device Automounter` enabled by default.
VeraCrypt itself can call ntfs-3g, but KDE's daemon still grabs the mount.
The temporary solution is to turn off `Removable Device Automounter`.

STEPS TO REPRODUCE
1. Open veracrypt
2. Mount an encrypted drive
3. udisks2 competes with ntfs-3g for the mount opportunity
OBSERVED RESULT
udisks2 sometimes fails to pop up the authentication box because the following error occurs.
Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.udisks2.filesystem-mount-system for system-bus-name::1.20 [/usr/bin/kded5] (owned by unix-user:username)The following result will appear when udisks2 successfully obtains permissions.
May 16 23:25:19 mid audit[1306]: DM_CTRL module=crypt op=ctr ppid=1117 pid=1306 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=2 comm="dmsetup" exe="/usr/bin/dmsetup" dev=253:0 error_msg='success' res=1
May 16 23:25:19 mid kernel: audit: type=1338 audit(1652714719.059:139): module=crypt op=ctr ppid=1117 pid=1306 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=2 comm="dmsetup" exe="/usr/bin/dmsetup" dev=253:0 error_msg='success' res=1
May 16 23:25:19 mid audit[1306]: SYSCALL arch=c000003e syscall=16 success=yes exit=0 a0=6 a1=c138fd09 a2=5599971ede90 a3=0 items=6 ppid=1117 pid=1306 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=2 comm="dmsetup" exe="/usr/bin/dmsetup" key=(null)
May 16 23:25:19 mid audit: CWD cwd="/home/chen"
May 16 23:25:19 mid audit: PATH item=0 name=(null) inode=1025 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PATH item=1 name=(null) inode=25857 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PATH item=2 name=(null) inode=27 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PATH item=3 name=(null) inode=25858 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PATH item=4 name=(null) inode=25858 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PATH item=5 name=(null) inode=25859 dev=00:07 mode=0100444 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid audit: PROCTITLE proctitle=646D7365747570006372656174650076657261637279707431
May 16 23:25:19 mid kernel: audit: type=1300 audit(1652714719.059:139): arch=c000003e syscall=16 success=yes exit=0 a0=6 a1=c138fd09 a2=5599971ede90 a3=0 items=6 ppid=1117 pid=1306 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=2 comm="dmsetup" exe="/usr/bin/dmsetup" key=(null)
May 16 23:25:19 mid kernel: audit: type=1307 audit(1652714719.059:139): cwd="/home/chen"
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=0 name=(null) inode=1025 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=1 name=(null) inode=25857 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=2 name=(null) inode=27 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=3 name=(null) inode=25858 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=4 name=(null) inode=25858 dev=00:07 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1302 audit(1652714719.059:139): item=5 name=(null) inode=25859 dev=00:07 mode=0100444 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
May 16 23:25:19 mid kernel: audit: type=1327 audit(1652714719.059:139): proctitle=646D7365747570006372656174650076657261637279707431
May 16 23:25:19 mid kernel: ntfs3: Unknown parameter 'windows_names'
May 16 23:25:19 mid udisksd[1317]: Failed to write lock '/dev/mapper/veracrypt1': Resource temporarily unavailable
May 16 23:25:19 mid udisksd[1317]: Error opening '/dev/mapper/veracrypt1': Resource temporarily unavailable
May 16 23:25:19 mid udisksd[1317]: Failed to mount '/dev/mapper/veracrypt1': Resource temporarily unavailable
May 16 23:25:19 mid ntfs-3g[1318]: Version 2021.8.22 external FUSE 29
May 16 23:25:19 mid ntfs-3g[1318]: Mounted /dev/mapper/veracrypt1 (Read-Write, label "data", NTFS 3.1)
May 16 23:25:19 mid ntfs-3g[1318]: Cmdline options: rw,uid=1000,gid=1000,umask=077
May 16 23:25:19 mid ntfs-3g[1318]: Mount options: allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/mapper/veracrypt1,blkdev,blksize=4096
May 16 23:25:19 mid ntfs-3g[1318]: Global ownership and permissions enforced, configuration type 7EXPECTED RESULT
udisks2 no longer competes with ntfs-3g for mount opportunities.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.17.7-arch1-1 (64-bit)I suspect this is a dbus configuration problem, but I haven't found any more information about it.
I am currently using this post's configuration as a temporary solution
https://bbs.archlinux.org/viewtopic.php?id=271384
Last edited by ohosmp (2022-05-17 03:15:56)
Offline
Just a guess but is it possible that you have a corresponding entry in fstab that kicks in here for udisks2?
sys2064
Offline
Just a guess but is it possible that you have a corresponding entry in fstab that kicks in here for udisks2?
I have checked and there is none.
Last edited by ohosmp (2022-05-16 22:31:49)
Offline
I have tested other desktop environments without this problem.
I think I should report this problem to KDE official, but I don't know which category I should send this problem to.
Last edited by ohosmp (2022-05-17 02:34:34)
Offline
That automounter could be 'udiskie'. Maybe one can blacklist some paths/devices, not sure.
On the other hand, this function is actually a good thing to mount as ntfs3. As far as i know Veracrypt is not able to do so (ntfs-3g only atm). So, you could turn off automount in Veracrypt instead.
sys2064
Offline
You might actually just want to have an fstab listing for this device right off the bat. Plasma's auto-disk mounting feature runs secondary to whatever you have in your fstab, so if you configure your mount points there instead it would probably stop Plasma from trying to steal it from you.
Not entirely sure how veracrypt works but if it's anything like LUKS once you unlock the drive it will have another device inside it that you are actually able to mount, and this is the device you should have in your fstab.
"Navigating one's life is like being a pathfinding algorithm with no paths to find." - Ghandi, probably
Offline
You can disable plasma's automounter on a per device basis as well. Check the removable media settings in system settings or
kcmshell5 kcm_device_automounterOffline
You can disable plasma's automounter on a per device basis as well. Check the removable media settings in system settings or
kcmshell5 kcm_device_automounter
Even with udisks authentication request turned off, ntfs-3g always mounts first, so I need to try many times to get udisks to mount instead of ntfs-3g, and the number of attempts I need with multiple encrypted partitions is exponential, so I'd rather choose to turn off KDE automount daemon.
Last edited by ohosmp (2022-05-18 00:20:32)
Offline
Not entirely sure how veracrypt works but if it's anything like LUKS once you unlock the drive it will have another device inside it that you are actually able to mount, and this is the device you should have in your fstab.
https://www.reddit.com/r/tails/comments … veracrypt/
LUKS occurs at a much lower level, and veracrypt's working mechanism and looks nothing like LUKS. At the moment it seems that can only turn off the KDE automount daemon or wait for veracrypt to be willing to make changes for this.
Last edited by ohosmp (2022-05-18 00:33:46)
Offline