Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#23184 - [truecrypt] dismount fails with Error: device-mapper: remove ioctl failed: Device or resource busy

Attached to Project: Arch Linux
Opened by ilya (leniviy) - Tuesday, 08 March 2011, 09:53 GMT
Last edited by Eric Belanger (Snowman) - Monday, 30 January 2012, 19:19 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Paul Mattal (paul)
Architecture i686
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No


Can't dismount with truecrypt. But if I do 'umount' first, it succeeds.
* package version(s)
truecrypt 7.0a-2, did pacman -Suy
* config and/or log files etc.
Mar 8 12:42:09 IL kernel: device-mapper: ioctl: unable to remove open device truecrypt1
This task depends upon

Closed by  Eric Belanger (Snowman)
Monday, 30 January 2012, 19:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  This bug was fixed in newer versions of ntfs-3g and truecrypt and does not affect arch users anymore.
Comment by Lars Bäckström (SNix) - Thursday, 10 March 2011, 00:10 GMT
I get this as well.
Comment by ilya (leniviy) - Thursday, 10 March 2011, 07:41 GMT
Other symptoms:
- umount /dev/dm-? fails, although it's in /etc/mtab
- in tc window mount point is empty
Comment by Ifai Gios (ifaigios) - Saturday, 12 March 2011, 11:57 GMT
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.
Comment by Lars Bäckström (SNix) - Saturday, 12 March 2011, 12:24 GMT
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.
Comment by Donald Hines (Kilarin) - Thursday, 24 March 2011, 14:18 GMT
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: with a lot of details.
Comment by Ifai Gios (ifaigios) - Sunday, 27 March 2011, 13:42 GMT
So, this is either a TrueCrypt upstream bug, or some kind of "incompatibility" between TrueCrypt and new versions of device-mapper.
Comment by David Runge (davezerave) - Tuesday, 12 April 2011, 18:25 GMT
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?
Comment by John Henderson (jwhendy) - Tuesday, 19 April 2011, 21:39 GMT
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 ( 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
Comment by Ifai Gios (ifaigios) - Wednesday, 20 April 2011, 13:16 GMT
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.
Comment by David Runge (davezerave) - Wednesday, 20 April 2011, 16:57 GMT
@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. :/
Comment by John Henderson (jwhendy) - Wednesday, 20 April 2011, 17:05 GMT
@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:

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.
Comment by ilya (leniviy) - Wednesday, 20 April 2011, 19:12 GMT
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,}
Comment by ilya (leniviy) - Wednesday, 20 April 2011, 19:26 GMT
mount.ntfs-3g behaves like mount --no-canonicalize, see mount(8)
Comment by Ifai Gios (ifaigios) - Wednesday, 20 April 2011, 19:44 GMT
@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.
Comment by ilya (leniviy) - Wednesday, 20 April 2011, 20:43 GMT
quick patch for ntfs-3g
Comment by Ifai Gios (ifaigios) - Thursday, 21 April 2011, 13:44 GMT
@leniviy: Thanks a lot, your patch works perfectly for me!
Comment by ilya (leniviy) - Thursday, 21 April 2011, 18:29 GMT
upgraded to ntfs-3g_ntfsprogs-2011.4.12 same problem. Here's the patch
Comment by Ifai Gios (ifaigios) - Sunday, 24 April 2011, 01:34 GMT
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)
Comment by Donald Hines (Kilarin) - Friday, 13 May 2011, 03:57 GMT
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?

Comment by Donald Hines (Kilarin) - Friday, 13 May 2011, 18:53 GMT
thanks to some incredible help from Ilya, I was able to install this patch, and it WORKS!!!!!

Thank you!
Comment by Ifai Gios (ifaigios) - Friday, 05 August 2011, 12:58 GMT
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: