You are not logged in.

#1 2022-05-16 16:58:54

ohosmp
Member
Registered: 2022-05-16
Posts: 6

[KDE] veracrypt udisks2 competes with ntfs-3g for mounts

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`.

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 7

EXPECTED 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

#2 2022-05-16 17:57:13

Maniaxx
Member
Registered: 2014-05-14
Posts: 761

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

Just a guess but is it possible that you have a corresponding entry in fstab that kicks in here for udisks2?


sys2064

Offline

#3 2022-05-16 22:15:03

ohosmp
Member
Registered: 2022-05-16
Posts: 6

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

Maniaxx wrote:

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

#4 2022-05-17 02:33:25

ohosmp
Member
Registered: 2022-05-16
Posts: 6

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

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

#5 2022-05-17 08:22:58

Maniaxx
Member
Registered: 2014-05-14
Posts: 761

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

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

#6 2022-05-17 09:08:18

nordkamp
Member
From: Queensland, AU
Registered: 2022-05-17
Posts: 10
Website

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

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

#7 2022-05-17 09:18:21

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 25,300

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

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

Offline

#8 2022-05-18 00:14:36

ohosmp
Member
Registered: 2022-05-16
Posts: 6

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

V1del wrote:

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

#9 2022-05-18 00:20:17

ohosmp
Member
Registered: 2022-05-16
Posts: 6

Re: [KDE] veracrypt udisks2 competes with ntfs-3g for mounts

nordkamp wrote:

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

Board footer

Powered by FluxBB