[Linux] Suddenly removed USB-disk, unable to Unmount the disk later

[alphaoumeric]

Expected behavior

Something removed & replug my USB disk's USB cable while mounting with Veracrypt. And when I click "Unmount" it simply says "disk is busy" and doesn't let me unmount the disk, even the disk is not in use. I unplug and plug it in and tried again but unmount still doesn't work. I had to restart the Debian just for this.

Observed behavior

Similar to Windows+Veracrypt, simply eject the Slot & display warning dialog.

Steps to reproduce

1. Mount the /dev/sdX to Slot 1.
2. Suddenly pull the USB cable and sinsert it immediately.
3. Click Slot 1 in Veracrypt GUI, click Unmount.

Screenshots

Your Environment

**VeraCrypt version:**1.26.24

Operating system and version: Debian 14

System type: amd64

[idrassi]

Thanks for the report.

This situation is different from a normal unmount. Once the USB device is physically removed while a VeraCrypt volume is mounted, Linux may still have an active filesystem mount and a /dev/mapper/veracryptN mapping referring to the old block-device instance. Replugging the USB device creates a new block-device instance: it does not reconnect the existing mounted stack.

So VeraCrypt cannot retroactively make this a clean unmount. Unflushed writes may already have failed and filesystem corruption is possible. However, needing a reboot just to clear a stale VeraCrypt slot is not ideal.

I checked the current Linux unmount path and there is a gap here: VeraCrypt first calls umount on the mounted filesystem. If Linux reports the mount as busy, the Linux path stops there and does not reach the later cleanup steps for VeraCrypt’s device-mapper/loop/FUSE objects. Also, VeraCrypt current Linux --force path is not equivalent to the Windows force-unmount behavior in this case.

I will look into adding a Linux-specific emergency cleanup path for stale or removed device situations: after a failed normal unmount, and only after an explicit warning/confirmation, detach the filesystem mount and remove or schedule removal of VeraCrypt device-mapper/loop/FUSE objects. This would be a recovery operation, not a safe unmount, and cleanup may still remain pending until processes close their open handles.

For now, please always unmount in VeraCrypt before physically removing the device. If you can reproduce this without rebooting, please provide the output of the following commands. For slot 1, the device-mapper name is normally veracrypt1: adjust it if you used another slot. You can redact serial numbers or unrelated process names before posting publicly.

MOUNTPOINT=/media/veracrypt1
DM_NAME=veracrypt1

veracrypt -t -v --list
findmnt -R -- "$MOUNTPOINT"
sudo fuser -vm -- "$MOUNTPOINT"
lsblk -o PATH,NAME,MAJ:MIN,RM,TYPE,SIZE,MODEL,TRAN,SERIAL,MOUNTPOINTS
sudo dmsetup info -c "$DM_NAME"
sudo dmsetup status "$DM_NAME"
sudo dmsetup ls --tree
sudo dmesg -T | tail -n 120

This will help distinguish open-file references from a stale filesystem/device-mapper state after the USB device was removed.

[alphaoumeric]

However, needing a reboot just to clear a stale VeraCrypt slot is not ideal.

Actually I observed sudden disconnection again on other Debian PC. I now think my Disk-to-USB storage kit itself is broken.
But I was able to dismount it without reboot - after I plug it in again twice.

I will look into adding a Linux-specific emergency cleanup path for stale or removed device situations: after a failed normal unmount, and only after an explicit warning/confirmation, detach the filesystem mount and remove or schedule removal of VeraCrypt device-mapper/loop/FUSE objects.

Yes, show a warning dialog like "Unmount failed. Do you want to attempt force unmount? This may brick your device!" with NO/yes button.

Additionally, VC-GUI could ask the user to run "fsck" (iirc it is ext4 fix program)

For now, please always unmount in VeraCrypt before physically removing the device.

Yes, I always unmount the device after use. I'm long term user since TrueCrypt era.

If you can reproduce this without rebooting, please provide the output of the following commands.

My journalctl is on volatile storage to save SSD writecount, so I don't have useful logs. However I found:

kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0
kernel: sd 6:0:0:0: [sdb] Write Protect is off
kernel: sd 6:0:0:0: [sdb] Mode Sense: 37 00 00 08
kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
kernel:  sdb: sdb1
kernel: sd 6:0:0:0: [sdb] Attached SCSI disk
udisksd[863]: Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sdb': Unexpected sense data returned:
                                 0000: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                 0010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                  (g-io-error-quark, 0)

I'm ordering new Disk-to-USB kit to replace current one just in case. If this doesn't work them this may be a disk problem.

[idrassi]

Thanks for the additional details.

I have implemented a Linux specific emergency cleanup path in master: abd0891

With this change, if normal unmount fails on Linux, VeraCrypt can now offer an explicit emergency cleanup option after a warning and confirmation dialog. This recovery path lazy detaches the filesystem mount and removes, or schedules removal of, the VeraCrypt device-mapper, loop and FUSE objects so that a stale slot caused by a removed/disconnected device should no longer require a reboot.

For CLI use, I also added --emergency-unmount to be used together with --unmount.

This remains a recovery operation, not a safe unmount: if the USB device was disconnected while mounted, pending writes may already have failed and filesystem corruption may have occurred. After using this path, the filesystem should be checked with fsck or the appropriate repair tool before using it again.

This change is only intended to handle stale/removed-device situations more gracefully when they do happen.

[alphaoumeric]

@idrassi I have an update on this situation.

I observed same issue on friend's computer (Debian+VC gui) with USB stick (not mine, encrypted by VC with exFAT).

Below is logs you requested. Hope this helps!

---

root@developer:~# MOUNTPOINT=/media/veracrypt1
DM_NAME=veracrypt1

root@developer:~# fuser -vm -- "$MOUNTPOINT"
No process specification given
Usage: fuser [-fIMuvw] [-a|-s] [-4|-6] [-c|-m|-n SPACE]
             [-k [-i] [-SIGNAL]] NAME...
       fuser -l
       fuser -V
Show which processes...............

root@developer:~# dmsetup info -c "$DM_NAME"
Name             Maj Min Stat Open Targ Event  UUID                            
veracrypt1       254   2 L--w    1    1      0        
                         
root@developer:~# dmsetup status "$DM_NAME"
0 30322176 crypt 

root@developer:~# dmsetup ls --tree
debian--vg-root (<REDACTED>)
 └─<REDACTED>
veracrypt1 (254:2)
 └─ (8:16)

root@developer:~# dmesg -T | tail -n 120
[<REDACTED>21:17 2026] usb 2-7.2: new high-speed USB device number 20 using xhci_hcd
[<REDACTED>21:17 2026] usb 2-7.2: New USB device found, idVendor=<REDACTED>, idProduct=<REDACTED>, bcdDevice= 1.10
[<REDACTED>21:17 2026] usb 2-7.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[<REDACTED>21:17 2026] usb 2-7.2: Product: USB Flash Disk
[<REDACTED>21:17 2026] usb 2-7.2: Manufacturer: <REDACTED>
[<REDACTED>21:17 2026] usb 2-7.2: SerialNumber: <REDACTED>
[<REDACTED>21:17 2026] usb 2-7.2: Device is not authorized for usage

("usbguard allow-device xyz" to allow the device)

[<REDACTED>21:41 2026] usb-storage 2-7.2:1.0: USB Mass Storage device detected
[<REDACTED>21:41 2026] scsi host2: usb-storage 2-7.2:1.0
[<REDACTED>21:41 2026] usb 2-7.2: authorized to connect
[<REDACTED>21:42 2026] scsi 2:0:0:0: Direct-Access     <REDACTED>  USB Flash Disk   1.00 PQ: 0 ANSI: 6
[<REDACTED>21:42 2026] sd 2:0:0:0: Attached scsi generic sg2 type 0
[<REDACTED>21:43 2026] sd 2:0:0:0: [sdb] 30322688 512-byte logical blocks: (15.5 GB/14.5 GiB)
[<REDACTED>21:43 2026] sd 2:0:0:0: [sdb] Write Protect is off
[<REDACTED>21:43 2026] sd 2:0:0:0: [sdb] Mode Sense: 45 00 00 00
[<REDACTED>21:43 2026] sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[<REDACTED>21:43 2026] sd 2:0:0:0: [sdb] Attached SCSI removable disk

(here, I was unable to unmount the drive from VC GUI so I had to plug out the device)
(then I added back in)

[<REDACTED>08:23 2026] usb 2-7.2: USB disconnect, device number 20
[<REDACTED>08:29 2026] usb 2-7.2: new high-speed USB device number 21 using xhci_hcd
[<REDACTED>08:30 2026] usb 2-7.2: New USB device found, idVendor=<REDACTED>, idProduct=<REDACTED>, bcdDevice= 1.10
[<REDACTED>08:30 2026] usb 2-7.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[<REDACTED>08:30 2026] usb 2-7.2: Product: USB Flash Disk
[<REDACTED>08:30 2026] usb 2-7.2: Manufacturer: <REDACTED>
[<REDACTED>08:30 2026] usb 2-7.2: SerialNumber: <REDACTED>
[<REDACTED>08:30 2026] usb 2-7.2: Device is not authorized for usage
[<REDACTED>08:40 2026] usb-storage 2-7.2:1.0: USB Mass Storage device detected
[<REDACTED>08:40 2026] scsi host3: usb-storage 2-7.2:1.0
[<REDACTED>08:40 2026] usb 2-7.2: authorized to connect
[<REDACTED>08:41 2026] scsi 3:0:0:0: Direct-Access     <REDACTED>  USB Flash Disk   1.00 PQ: 0 ANSI: 6
[<REDACTED>08:41 2026] sd 3:0:0:0: Attached scsi generic sg2 type 0
[<REDACTED>08:42 2026] sd 3:0:0:0: [sdc] 30322688 512-byte logical blocks: (15.5 GB/14.5 GiB)
[<REDACTED>08:42 2026] sd 3:0:0:0: [sdc] Write Protect is off
[<REDACTED>08:42 2026] sd 3:0:0:0: [sdc] Mode Sense: 45 00 00 00
[<REDACTED>08:42 2026] sd 3:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[<REDACTED>08:42 2026] sd 3:0:0:0: [sdc] Attached SCSI removable disk
[<REDACTED>08:55 2026] exFAT-fs (dm-3): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[<REDACTED>09:02 2026] usb 2-7.2: USB disconnect, device number 21

---

developer@developer:~$ MOUNTPOINT=/media/veracrypt1
DM_NAME=veracrypt1

developer@developer:~$ veracrypt -t -v --list
Slot: 1
Volume: /dev/sdb
Virtual Device: /dev/mapper/veracrypt1
Mount Directory: /media/veracrypt1
Size: 14.5 GiB
Type: Normal
Read-Only: No
Hidden Volume Protected: No
Encryption Algorithm: AES
Primary Key Size: 256 bits
Secondary Key Size (XTS Mode): 256 bits
Block Size: 128 bits
Mode of Operation: XTS
PKCS-5 PRF: HMAC-SHA-512
Volume Format Version: 2
Embedded Backup Header: Yes

developer@developer:~$ findmnt -R -- "$MOUNTPOINT"
TARGET         SOURCE                FSTYPE OPTIONS
/media/veracrypt1
               /dev/mapper/veracrypt1
                                     exfat  rw,noatime,uid=1000,gid=1000,fmask=0077,dmask=0077,iocharset=utf8,error

developer@developer:~$ lsblk -o PATH,NAME,MAJ:MIN,RM,TYPE,SIZE,MODEL,TRAN,SERIAL,MOUNTPOINTS
PATH                    NAME             MAJ:MIN RM TYPE    SIZE MODEL           TRAN   SERIAL          MOUNTPOINTS
/dev/sda <REDACTED>
/dev/zram0 <REDACTED>

developer@developer:~$ 

I was able to extract those logs even the device is unplugged, so clearly VC is not clearing it.

[idrassi]

@alphaoumeric
Thanks for the logs. They are useful and they confirm the stale state described earlier: Linux kept the VeraCrypt mapper/filesystem stack alive after the USB device disappeared.

This is exactly the case addressed by the new emergency cleanup path added in commit abd0891

You can test it by building from current master.
With this change, if normal unmount fails, VeraCrypt offers an explicit warning/confirmation dialog to attempt emergency cleanup of the stale mount and VeraCrypt kernel objects.

One small note about the diagnostic command: the fuser command should be run without -- here:

sudo fuser -vm "$MOUNTPOINT"

[alphaoumeric]

Thank you for the fix - I'll wait for official release and will report back if it doesn't solve the issue.

Closing this issue for now.