1

I have an external, encrypted USB-drive that was mounted through dm-crypt: The device was /dev/sdb, decrypted as /dev/mapper/external (which is a symbolic link to /dev/dm-5) and mounted as /mnt. After suspending the system to ram and resuming, the USB-drive was unfortunately disconnected, and after reconnecting, it now appears as /dev/sdc. Accessing /mnt gives I/O-errors, understandably.

Is it possible to change the underlying device of a dm-crypt volume while it is active? Or is it possible to change the underlying block device of a mount without unmounting? Ideally open file handles from the drive should still be valid afterwards.

There are processes that have files open on the device, but they were suspended with SIGTSTP and buffers were flushed via sync before this. I want these processes to resume without getting IO-errors. The USB-device is in the same state as before being detached as there has been no write-access to it, so I believe this should at least in principle be possible.

E.g. if I managed to get the usb drive have its old /dev/sdb device (how?), would the old mount point work again? Or if I opened the device as a new dm-crypt device and changed the target of the /dev/mapper/external symbolic link?

3
  • 1
    The errors already happened, so even if you could - it would not solve your problem. The filesystem state already deviates (in-memory vs. on-disk) so you'd end up with even more corruption issues. Commented Apr 15, 2022 at 19:04
  • 2
    That said if you freeze it beforehand (cryptsetup luksSuspend) so all I/O is halted, and then make sure the device is operational in some fashion, you may be able to tinker it with dmsetup, for example - but it's dangerous to do these things. No idea if it can be done properly. Ideally the kernel should make sure that all devices are re-established on resume... I don't use suspend/resume at all for this reason, there are way too many things that can go wrong to be worth it... Commented Apr 15, 2022 at 19:23
  • Your use case is one that security software explicitly guards against. "Change my underlying media and try to use the same authentication? It's a trick! " Commented Apr 16, 2022 at 1:38

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.