While I was away from my computer, my encrypted USB drive got accidentally unmounted somehow (although it was still physically connected at the time). I haven't been able to recover (haven't tried a reboot yet). I have now completely disconnected the device, but I still get "Device or resource busy" when I try to remove the dangling entry in /dev/mapper. Can I reconnect and mount the drive without a reboot?

Here's what I have tried (long name changed to "xxxxx")...

$ sudo dmsetup ls
luks-xxxxx (252:1)
luks-yyyyy (252:0)

$ sudo umount /dev/mapper/luks-xxxxx
umount: /dev/mapper/luks-xxxxx: not mounted

$ sudo fuser --kill /dev/mapper/luks-xxxxx
$ echo $?

$ sudo dmsetup info -c luks-xxxxx
Name       Maj Min Stat Open Targ Event  UUID
luks-xxxxx 252   1 L--w    1    1      0 CRYPT-LUKS1-xxxxx-luks-xxxxx

$ sudo dmsetup remove luks-xxxxx
device-mapper: remove ioctl on luks-xxxx failed: Device or resource busy
Command failed

After reconnecting the device...

$ sudo cryptsetup luksOpen "/dev/sde1" "luks-xxxxx"
Device luks-xxxxx already exists.

[EDIT] I solved the problem, this time, by closing a GUI text editor which had no open files, but had been launched from a folder on the device in question. So the question becomes more specific: How can you identify which application is holding the device open?

Bear in mind that lsof doesn't seem to present an easy solution because, once the device is disconnected, the associated names provided by lsof no longer include the name of the disconnected device.

  • Running into the same problem but on CentOS. Found this link: krenel.org/… but I don't show the device mounted Jun 9, 2014 at 11:48
  • Seems remarkably similar to this closed-as-fixed bug report: bugs.debian.org/cgi-bin/bugreport.cgi?bug=574126 Mar 9, 2016 at 20:50
  • Word of warning: Mounting with sudo, as shown here, may prevent you from ejecting normally using the user-space file-manager. Jun 11, 2017 at 22:31
  • This hasn't happened to me much lately, but today it did (I accidentally unplugged a drive). On Ubuntu 18.04, the error is "Failed to activate device File exists", but it doesn't give much help regarding what file (or what luks-xxxx name). Fortunately, I was able to identify that by looking at /dev/disk/by-uuid with and without the drive connected. The solution was the same as before (sudo dmsetup ls followed by sudo lsof |grep xxx,x followed by closing/killing processes). May 4, 2021 at 16:41

5 Answers 5


After two years of fighting with this, I think I've finally cracked it completely!

dmsetup ls gives you the data you need:

$ sudo dmsetup ls
luks-xxxxx (252:1)


sudo lsof |grep 252,1   ## notice translation: (252:1) => 252,1

It seems that sudo may be critical here -- at least in some cases.

This should give you the information necessary to close all open files on the device -- including names of open files and process IDs for the offending applications. You may be able to simply go to those apps and close them, but a brute force approach might be something like:

kill -9 (process ID)

Once you've closed all the files, some of the command-line tools shown in the question may be necessary in order to close down the existing mount before it can be reopened normally.

  • 5
    Notice the slight translation required: (252:1) becomes 252,1. Aug 17, 2016 at 23:04
  • Amazing, thanks for this response that finally works! Jun 5, 2020 at 22:28
  • 1
    hm. weirdly enough, lsof doesn't show any processes holding handles on the (stale) device. Apr 11, 2021 at 8:21
  • Unfortunately sudo lsof |grep 253:3 didn't work for me lsof. There was no output on stdout, and on stderr 100s of errors like no pwd entry for UID 70
    – Tyler Rick
    Aug 1 at 18:37
  • @TylerRick, Notice the slight translation required: (253:3) becomes grep 253,3. I don't know about your stderr issues but this translation is probably necessary to get results on stdout. Aug 1 at 19:56

Try to stop LVM group prior to stop cypher:

lvchange -a n [LVM_Group_name]


cryptsetup -v luksClose [LUKS_name]


lvchange -a n My_vg_crypt
cryptsetup -v luksClose My_Crypt
  • 2
    Use @nobar's answer first (but try kill before kill -9). However @nobar's solution wasn't sufficient for me - it seems that the kernel itself had the device open because of the LVM device mappings - which this answer resolved.
    – Tom Hale
    Nov 15, 2016 at 9:27
  • +1 In my case the accepted answer's grep didn't find any matches, but this worked.
    – user000001
    Jan 18, 2019 at 9:52

next time try a lazy umount

umount -l /<folder>

This works for me most of the times, especially useful with hung-up NFS-drives.

  • I tried this, but didn't help for the problem at hand. I'm assuming that you can't actually use LUKS over NFS, and that this was just a shot-in-the-dark suggestion. May 9, 2016 at 13:38
  • this was exactly my problem, i forgot that i need to unmount mapped storage first :D
    – holms
    Dec 18, 2016 at 10:25

Here is how I manage to solve this problem on Linux Mint 17.3 (~Ubuntu Trusty):

  1. remove the device from device-mapper

    $ sudo dmsetup remove luks-xxyyzz
  2. map it back

    $ sudo cryptsetup open /dev/sdc1 luks-xxyyzz
    Enter passphrase for /dev/sdc1:

Now the devices is accessible.

  • 2
    This post might be helpful to someone, but as noted in the question -- sometimes dmsetup remove reports "Command failed". Mar 8, 2016 at 23:36

I was in a similar situation but could not solve the problem by removing the luks-xxxx device. Instead I had to remove ubuntu--vg-root.

My situation was:

  • I accidentally removed the device before it was locked.
  • Trying to lock or remove the luks device after the fact failed with a busy error message.
  • Unlocking the same device failed because a device with the same name already existed.
  • lsof did not show any open handles for the device.

What did help was to unplug the physical device and remove the ubuntu--vg-root device with the following command:

sudo dmsetup remove ubuntu--vg-root

At that point I was able to normally activate and decrypt the external device again with my usual setup:

udisksctl unlock -b /dev/sda3
sudo lvchange --activate y ubuntu-vg/root
  • I had a similar problem with an internal disk. After vgscan did not return any results despite the fact that the volume groups were there and accessible, this was the last resort that finally solved my problem.
    – Stanley F.
    Jul 7 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.