I have a USB flash drive with Full Disk Encryption using LUKS. I plugged in the drive and mounted it as such using the following:

cryptsetup luksOpen /dev/sdb flash
mount /dev/mapper/flash /mnt/flash

If I physically remove my flash drive I can still access it's contents at /mnt/flash. Why is this? I see it as a security risk as I want my flash drive contents to become inaccessible as soon as the drive is physically removed.

What can I do to make this happen? It needs to be something I can do to the drive as I use this on other computers and I don't want to have to change them all to make the drive secure.

  • Could be just a few cached files & entries. How much data can you actually read/copy? After flushing the disk caches can you still read anything? ps. you'll probably corrupt the filesystem if it was mounted rw by yanking it out
    – Xen2050
    Commented Aug 23, 2017 at 12:25
  • Well my SSH private key is on there, and I can still use it to authenticate via SSH to other machines. Desirable behavior would be that if it was removed the key would not remain usable in RAM.
    – Patrick
    Commented Aug 23, 2017 at 12:34
  • 1
    Interestingly, I think the data may remain in ram even after cleanly unmounting & luksClose & removing it, it just might be marked as "free", not unlike deleting a file. But unmounting first sounds like your answer, even a quick alias or desktop shortcut or something to click. Or, write a program/script that looks for the device every so often, and tries to umount it if it's missing. Or, switch off all the power after pulling out the usb (or before, wouldn't matter) would ensure nothing's easily accessible.
    – Xen2050
    Commented Aug 23, 2017 at 12:47
  • "Or, write a program/script that looks for the device every so often, and tries to umount it if it's missing. " That seems like a great solution, actually, Thanks!
    – Patrick
    Commented Aug 23, 2017 at 14:29
  • 1
    Sorry, I thought I gave you a +1, I just did now. :)
    – Patrick
    Commented Aug 24, 2017 at 13:20

2 Answers 2


You seem to be skipping some steps in the process. You should:

  • Insert the drive
  • cryptsetup luksOpen /dev/sdb flash
  • mount /dev/mapper/flash /mnt/flash
  • Use the drive as normal
  • umount /mnt/flash
  • cryptsetup close flash
  • Remove the drive

The inverse of mount is umount. Trying to umount a non-inserted drive may hang, depending on what the system is trying to do. The cryptsetup close step further removes the drive's mapping and wipes the encryption key from kernel memory.

You cannot guarantee that all (meta-)data is properly written to the device if you physically remove it without calling umount. Your encryption key is still available in memory until you call cryptsetup close. With that in mind, these steps should not be skipped.

  • Right. I understand that it shouldn't be removed without properly closing and unmounting. But in this scenario is there a failsafe I can use to ensure that the drive automatically unmounts or cryptsetup closes the drive upon the drive physically being removed? I have my SSH key on here and I don't want it accessible after I remove the drive if I don't unmount properly.
    – Patrick
    Commented Aug 16, 2017 at 2:53
  • @Patrick After removing a drive, you can try a umount -f to force an unmount (but this has a chance to hang), or umount -l to at least make the files inaccessible until a real unmount can occur.
    – Fox
    Commented Aug 16, 2017 at 3:06
  • That'll have to do. I was hoping there was an automated way...
    – Patrick
    Commented Aug 16, 2017 at 3:11
  • How could a savagely unplugged drive be unmounted auto[mg]atically after the fact? Even Windows can't do it (hence the tray icon)! If you're using a GUI, you can umount the drive from a file manager like Nautilus before unplugging the drive, way easier than using the command line, you can also mount your drive from a file manager.
    – cylgalad
    Commented Aug 16, 2017 at 7:46
  • @cylgalad My comment was only meant to imply "make the file tree inaccessible" rather than a true unmount
    – Fox
    Commented Aug 16, 2017 at 9:11

If you ran a program / script from the USB itself, you should be able to figure out what LUKS map/name and device it's on (or just tell the script the device or mapped name if you know it) and watch for when the device "disappears" when it's removed. Then unmount it.

I'm pretty sure that unplugging a USB will cause the device (/dev/sdXn) to disappear, but in case it doesn't you'd have to watch dmesg or look in the syslog, or find it somewhere in /sys perhaps.

Here's a proof-of-concept bash script that looks like it should work, but I don't have any LUKS partitions on usb's to test with, so I'm not sure if umount might need options like --lazy or --force.

map=$( df --output=source $PWD |tail -n1 )

device=$( sudo cryptsetup status "$map" | grep -o "device:.*"|cut -d' ' -f 3 )

while [ -b "$device" ]
    sleep 30

echo "Device $device is missing, unmounting"
sudo umount -v "$map"

If it's run from inside the mounted LUKS container, $PWD should find the LUKS name it's mapped on, and then the device, and if the device stops being a block special file then unmount the mapped device.

PS If the device was mounted rw (writeable) the filesystem can be corrupted by suddenly unplugging it. FAT seems especially vulnerable, while a journaling filesystem should be more robust. If it's mounted ro (read-only) at least you could avoid that problem, mount accepts -o ro and cryptsetup accepts --readonly (both probably aren't necessary)

  • I've tried this but umount.crypt just core-dumps. I'm using ubuntu 22.04. What's the alternative?
    – brunoais
    Commented Apr 4, 2023 at 7:32
  • 1
    I'm not sure, even with the --lazy or --force options? Core dumps are usually bugs... Could try to close the device with cryptsetup, perhaps with it's --deferred option. Or call dmsetup's remove or clear or wipe_table commands?
    – Xen2050
    Commented Apr 4, 2023 at 9:11
  • Thank you for the quick answer (I only got to know now). The lazy option works but then I cannot reconnect. With --force it core-dumps. I'll try those other options next time it happened (I ended up rebooting). I didn't know they existed. Thank you very much.
    – brunoais
    Commented Apr 5, 2023 at 10:49
  • ($PWD is /dev/mapper) dmsetup remove -f _dev_sda causes log: Buffer I/O error on dev dm-6, logical block 2468362112, async page read. dmsetup remove -f is successful, dmsetup clear -f is successful, dmsetup wipe_table -f is successful but then dmsetup remove -f still doesn't work.
    – brunoais
    Commented Apr 5, 2023 at 16:05
  • 1
    Ah, usb can be temperamental, fixing that bug would be best. I keep a usb drive always connected and it hasn't "flickered out" before, although when I used FAT it would get corrupted regularly, no problems with ext, but yours sounds like a hardware issue. Definitely try the usual: new cords & hub, different port, etc. Maybe even a newer/older kernel? I'm not sure how much further to go with the disconnect-detecting script, I spotted a hdparm option "-w device reset (DANGEROUS)" that might work for a hard drive-like drive, maybe not a thumb drive. But maybe upvote if something's been helpful?
    – Xen2050
    Commented Apr 12, 2023 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .