In the initial description I had mentioned that disk utility does not lock the drive after creating it.
I have just discovered another way to get this error:
1) Plug in a LUKS encrypted disk
2) At the password prompt unlock it (Disk will mount and be displayed on the desktop)
3) Suspend computer
4) On resume, "Device already exists" error is shown.
After discussing this with other users we feel that this issue could be corrected in cryptsetup, or al least the graphical front end for it. A dialog stating "A mapper point for this encrypted drive exists already therefore the disk could not be mounted, would you like us to try and fix this (Y/n)".
Another method of correcting this would be to have cryptsetup work on a message bus where when the device is present, the mapping point is created and managed by those messages. Once the device is removed, the encrypted mapper point is removed as well (not just the mountpoint).
I know this is all very confusing and this is the best way I know to explain it:
A-Disk Device
B -Encrypted Device
C -Mapper Point Device (Unencrypted/Unlocked Device)
D -Mountpoint
E -Filesystem
The issue is that if C is not cleanly closed (disk being removed without being locked/luksClose) it blocks anyone from using that drive ever again on that computer (workaround listed in description). It would be nice to cook up a solution which could be tested in the next few releases and ready for the next LTS.
In the initial description I had mentioned that disk utility does not lock the drive after creating it.
I have just discovered another way to get this error:
1) Plug in a LUKS encrypted disk
2) At the password prompt unlock it (Disk will mount and be displayed on the desktop)
3) Suspend computer
4) On resume, "Device already exists" error is shown.
After discussing this with other users we feel that this issue could be corrected in cryptsetup, or al least the graphical front end for it. A dialog stating "A mapper point for this encrypted drive exists already therefore the disk could not be mounted, would you like us to try and fix this (Y/n)".
Another method of correcting this would be to have cryptsetup work on a message bus where when the device is present, the mapping point is created and managed by those messages. Once the device is removed, the encrypted mapper point is removed as well (not just the mountpoint).
I know this is all very confusing and this is the best way I know to explain it: Unlocked Device)
A-Disk Device
B -Encrypted Device
C -Mapper Point Device (Unencrypted/
D -Mountpoint
E -Filesystem
The issue is that if C is not cleanly closed (disk being removed without being locked/luksClose) it blocks anyone from using that drive ever again on that computer (workaround listed in description). It would be nice to cook up a solution which could be tested in the next few releases and ready for the next LTS.