cryptsetup luksClose fails with "busy"

I tried this on current lucid with an USB stick (single partition, encrypted LUKS VFAT), and it works fine for me. Both with right click -> unmount and with the eject symbol in nautilus' bookmarks. Thus I need some further debug information from you, I'm afraid.

Please start with a clean slate, i. e. reboot or cryptsetup luksClose, so that /dev/mapper/ only has control. Now open a terminal and do

  udevadm monitor -e --udev >/tmp/udev.log 2>&1 &
  sudo /usr/lib/udisks/udisks-daemon --replace 2>&1 | tee /tmp/udisks.log

Now reproduce the situation, i. e. mount and unmount the partition, and verify that you get the cryptsetup failure.

Please press Control-C, do "fg", Control-C again, and attach /tmp/udisks.log and /tmp/udev.log here. Thanks!

2010/3/1 Martin Pitt <email address hidden>

> I tried this on current lucid with an USB stick (single partition,
> encrypted LUKS VFAT), and it works fine for me.

Note that I'm getting that error with an external *HDD*, NTFS partition. I
also tested a LUKS VFAT USB flash drive and yes, it is working just fine.

> Both with right click ->
> unmount and with the eject symbol in nautilus' bookmarks. Thus I need
> some further debug information from you, I'm afraid.
>

Attached

Thanks. The log shows that the "umount" command finished before "cryptsetup luksClose" is called, so cryptsetup should be able to luksClose. Reassigning to cryptsetup.

I'm still getting the exact same error message in amd64 Maverick while unmounting a cryptsetup encrypted NTFS partition that spans an entire external USB disk drive. I don't get this unmount error message if I replace the encrypted NTFS partition with an encrypted ext4 partition.

I've confirmed the above on two different amd64 Maverick systems: one that was upgraded from Lucid, and another that's a clean install.

Martin Pitt, I followed your instructions above and I've attached the two log files.

Hello,

I have the same problem. It occurs when unmounting the entirely LUKS encrypted internal SATA-300 ext4 HDD /dev/sdb1. The System is AMD / 64-bit Ubuntu 10.10. Then, after some more time of working, it suddenly works, don't know why. Hope the bug will be solved soon for more convenience. Thanks

Hello,

I'am the same pb using an external DD with 2 ntfs partitions (one uncrypted, one crypted)

Ubuntu 10.10, i386

Thanks

i have this issue too on lucid with cryptsetup 2:1.1.0~rc2-1ubuntu13 although the suggested work-around does not work for me. i've plugged in an external disk taken out of another ubuntu installation:

$ sudo cryptsetup luksOpen /dev/sde5 sde5_crypt
(this makes available the -root and -swap partitions in /dev/mapper)

$ sudo mount /dev/mapper/laptop-root /mnt/laptop-root
(now i have just moved some files from the partition and am ready to unmount)

$ sudo umount /mnt/laptop-root/
$ sudo cryptsetup luksClose sde5_crypt
Device sde5_crypt is busy.
$

is there any way to cleanly remove the drive without shutting down the whole system??

This bug also affects me. I have an external hardrive with (among other things) a volume group on it. One of the logical volumes is encrypted with LUKS and formatted ext4. Whenever I mount it graphically (via nautilus or the gnome mounting applet), it succeeds (after supplying the right password), but it behaves kind of oddly. The decrypted volume does not open "in place" (i.e.: under the icon I clicked on to decrypt it), but it creates another icon for the decrypted EXT4 drive. The original icon continues showing the option "Mount volume" (the option "Open volume" remains grayed out), but I can open the volume via the secondary icon. I can unmout the volume via the right-click menu of the secondary icon (causes the secondary icon to disappear) but trying to remount the the volume via the primary icon fails (even after supplying the right password) since the cryptsetup partition does not get closed/locked in /dev/mapper .

As a result
1) the super user (luckily me) can still see my encrypted data. All he has to do is mount the appropriate un(luks)Closed blockdevice in /dev/mapper
2) the owner of the encrypted partition can't reaccess their data without rebooting, unless he's a sudoer who can "cryptsetup luksClose /dev/mapper/uuid* " and do the graphical thing or mount the unlocked cryptsetup partition in /dev/mapper/ .

(P.S. Like khumbartha, I have also encountered the situation several times where I can't luksClose the the cryptsetup partition, even as the superuser I don't know how to reproduce it though -- but I think it happens if the external volume gets unplugged and replugged again an the logical volumes get reread.)

same issue, completely reproducible:
- from a cold boot (or any other starting condition)
- connect and power up external usb drive with encrypted LUKS volume in first partition
- use GUI or command line to unlock and mount volume
- use the volume for backup
- umount the encrypted volume
- attempt to lock (close) the encrypted block device

Encrypted data is still visible in nautilus, even though the mount table (mtab) no longer shows the presence of the device.

The difference: There is no way to lock/close the device.
manually running
/sbin/cryptsetup luksClose udisks-luks-uuid-...
yields:
Device udisks-luks-uuid-... is not active.
Device udisks-luks-uuid/... not found
depending on which UUID is used in place of the ellipsis

cryptsetup luksClose /sbin/cryptsetup luksClose /dev/disk/by-uuid/...
yields:
"Device ... is busy" message

the two UUIDs I'm working with:
/dev/sdc1: UUID="4e1a0099-6362-44a7-9435-3a87fb8add16" TYPE="crypto_LUKS"
/dev/mapper/external-mirror: UUID="a43905ea-0d70-4d5f-83e2-852ef930c0ad" TYPE="ext4"

Fascinating. I just had to use luksOpen to fix my freshly installed 14.04 ... and I ran into the very same problem: when going for luksClose; I get the "resource busy" error (running the command from a USB stick which contains ubuntu 14.04.2).