Arch Linux

I get this as well.

Other symptoms:
- umount /dev/dm-? fails, although it's in /etc/mtab
- in tc window mount point is empty

I experience this too. "sudo umount -a" works and dismounts all TrueCrypt volumes, but I don't think this is the proper way to dismount an TC filesystem. Probably the problem doesn't have to do with TrueCrypt itself, as this version (7.0a-2) previously worked just fine.

Could it have something to do with KDE? Like for example indexing or how KDE handles mounting of USB storage (I only use truecrypt on USB drives)?
If it's not Truecrypt itself then maybe we have something else in common.

I'm suffering with this as well. Seem to be a lot of people having this problem. There is a thread about it on the truecrypt forums: http://forums.truecrypt.org/viewtopic.php?t=22692 with a lot of details.

So, this is either a TrueCrypt upstream bug, or some kind of "incompatibility" between TrueCrypt and new versions of device-mapper.

As lots of people seem to have this problem in other distros I guess it's truecrypt related :/
Hope they'll fix it soon!! :(

After all, maybe something will change since ntfs-3g has been merged with ntfsprogs?

Edit: after re-reading the bug, perhaps this is what the problem was presented as in the first place. I will leave the below, as it wasn't this easy for me. 'truecrypt -d' would result in the ioctl error, but attempts to use 'umount' would result in "device not mounted" errors when applied to /dev/dm-1. lsof/fuser also reported no use of any of the related mount points. The steps below have been reliable so far, while my attempts to use the above have not.

----

While not ideal, I think I have a workaround for this. The idea struck me after setting this up recently via the wiki (https://wiki.archlinux.org/index.php/TrueCrypt). One can mount the truecrypt device to a slot with no filesystem like so:
,---
| $ sudo truecrypt --filesystem=none --slot=1 /dev/sdaX
`---

Enter the password, and then mount using the system mount command:
,---
| $ sudo mount /dev/mapper/truecrypt1 /media/tc
`---

I concur that the problem appears to be ntfs + truecrypt, but the above is working splendidly for me. I can just mount once with truecrypt and leave it alone mapped to /dev/mapper/truecrypt1 and then mount/umount from there to my mount point as needed.

In addition, once the mapper is unmounted from the mount point, I've had no problems at all with:
,---
| $ sudo truecrypt -d
`---

So, perhaps this is a workaround for others while this gets fixed?

Oh, and if it helps, here's my fstab line for this:
,---
| /dev/mapper/truecrypt1 /media/vault ntfs-3g uid=1000,gid=100,fmask=113,noatime 0 0
`---

A found a temporary solution to the problem too: I uninstalled ntfs-3g and now everything works fine! Obviously TreuCrypt doesn't get along with ntfs-3g, when installed.

@jwhendy: Sounds interesting. Will try it tomorrow. Right now I'm still unmounting ("sudo umount /media/truecryptX") before doing "truecrypt -d".
@ifaigios: Hmm, what about write-access with the kernels ntfs drivers? Will that still work, or will it revert to read-only? I think I still have ntfs and ntfs-3g symlinked here... oh noes. :/

@David Runge: I may try that. For some reason, I thought it didn't for me, but then again, I don't like my drive at /meadia/truecrypt#. I'd been running
,---
| truecrypt -t --filesystem=ntfs-3g -k "" --protect-hidden=no --fs-options=noatime /dev/sda4 /media/vault
`---

It didn't seem to like that and I couldn't umount /media/vault. On the other hand, if you do 'truecrypt -d' *first*, do you run into problems later? Maybe it's the first failed attempt that goofs things up?

@Ifai: how good is the default NTFS support in the kernel? Reading the help section when compiling didn't sound too promising. I even think not having ntfs-3g might have been the culprit for my wife's ridiculously slow Arch install, mentioned here: https://bbs.archlinux.org/viewtopic.php?pid=901563

Installing ntfs-3g and changing fstab from ntfs -> ntfs-3g *drastically* improved things and I haven't seen a 20-30sec hang since. She was up to date on Arch, running the default 2.6.38 kernel. Just curious about this.

Sorry for big post. I think mount.ntfs-3g puts bad entry to mtab

# disable ARCH's ntfs-3g hack
$ mv /sbin/mount.ntfs{,.1}

# -t ntfs puts correct entry to mtab

$ mount /dev/mapper/truecrypt1 /media/myprivate -t ntfs
$ mount
/dev/mapper/truecrypt1 on /media/myprivate type ntfs (ro)
$ umount /dev/mapper/truecrypt1

$ mount /dev/dm-7 /media/myprivate -t ntfs
$ mount
/dev/mapper/truecrypt1 on /media/myprivate type ntfs (ro)
$ umount /dev/mapper/truecrypt1

# -t ntfs-3g puts bad entry to mtab

$ mount /dev/mapper/truecrypt1 /media/myprivate -t ntfs-3g
$ mount
/dev/dm-7 on /media/myprivate type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
$ umount /dev/mapper/truecrypt1
umount: /dev/mapper/truecrypt1: not mounted
$ umount /dev/dm-7
umount: /dev/dm-7: not mounted
$ umount /media/myprivate

$ mount /dev/dm-7 /media/myprivate -t ntfs-3g
$ mount
/dev/dm-7 on /media/myprivate type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
$ umount /dev/mapper/truecrypt1
umount: /dev/mapper/truecrypt1: not mounted
$ umount /dev/dm-7
umount: /dev/dm-7: not mounted
$ umount /media/myprivate

# enable ARCH's ntfs-3g hack
$ mv /sbin/mount.ntfs{.1,}

mount.ntfs-3g behaves like mount --no-canonicalize, see mount(8)

@davezerave and @jwhendy: The kernel ntfs services provide very basic, read-only access. For this reason, it is recommended that we use the ntfs-3g driver for all NTFS-related operations. I think that writing is also possible via ntfs-fuse (included in ntfsprogs), but it is probably dangerous to use it for write access to NTFS volumes (it is considered to be replaced by ntfs-3g and not supported anymore)

@leniviy: Interesting. If ntfs-3g puts a bad entry to /etc/mtab, it is more that expected for TrueCrypt/device-mapper to fail to recognize and dismount the volume.

quick patch for ntfs-3g

@leniviy: Thanks a lot, your patch works perfectly for me!

upgraded to ntfs-3g_ntfsprogs-2011.4.12 same problem. Here's the patch

Thanks to ilya, here's the patch and PKGBUILD for the ntfs-3g_ntfsprogs-git package (the one in the AUR).

[Edit]: Please use the second tarball (the .tar.gz one), as I have made some mistakes in the first one (and I can't delete it for some reason)

Please excuse my ignorance. I am running Ubuntu 10.10 and Synaptic Package Manager shows my ntfs-3g version to be 1:2010.8.8-0ubuntu1.

Is it safe for me to just download and install ntfs-3g_ntfsprogs-git-with_canonicalize_path_patch.tar.gz ??

And, again, please pardon my stupidity, but exactly how would I install it?

thanks!

thanks to some incredible help from Ilya, I was able to install this patch, and it WORKS!!!!!

Thank you!

The bug was fixed in upstream ntfs-3g_ntfsprogs; next release should include the fix. Until then, either build ntfs-3g_ntfsprogs-git from the AUR or use this workaround: https://wiki.archlinux.org/index.php/TrueCrypt#Unmount_error_.28device_mapper.29