Ubuntu
cryptsetup package

Plugging in a LUKS device causes the following error: Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists

Bug #484429 reported by komputes
184
This bug affects 36 people
Affects Status Importance Assigned to Milestone
udisks
Fix Released
Medium
cryptsetup (Debian)
Fix Released
Unknown
cryptsetup (Ubuntu)
Confirmed
Medium
Unassigned
Lucid
Won't Fix
Medium
Unassigned
Maverick
Won't Fix
Medium
Unassigned
gnome-disk-utility (Ubuntu)
Invalid
Medium
Unassigned
Lucid
Invalid
Medium
Unassigned
Maverick
Invalid
Medium
Unassigned
udisks (Fedora)
Won't Fix
Medium
udisks (Ubuntu)
Fix Released
Medium
Martin Pitt
Lucid
Won't Fix
Medium
Unassigned
Maverick
Fix Released
Medium
Martin Pitt

Bug Description

Binary package hint: cryptsetup

When creating an encrypted drive in Palimsest (Disk Utility), the application does not lock the disk when finished creating the encrypted partition. Failing to lock the drive manually without ejecting will give the appearance that the disk is no longer usable giving this error. Bringing the key to another computer works because the drive is not unlocked (luks mapper point is not already present) on that system.

Steps to reproduce:
1) Go into palimsest (disk utility) and create an encrypted partition on an external disk.
2) Quit Palimsest
3) Pull the USB stick
4) Intert the USB stick

Result:
GNOME displays a dialog for the password. Once submitted, the following error comes up:
Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists

This is due to the mapping being Opened when the disk is created, but never closed, which creates a conflict.

Workaround:
Do the following to resolve the conflict of the existing device i /dev/mapper.
$ ls -al /dev/mapper
(Identify the mount point for your drive, "sudo blkid" may help)
$ sudo cryptsetup luksClose devkit-disks-luks-uuid-<uuid>-uid1000

What is expected:
Palimsest (Disk Utility) is expected to "cryptsetup luksClose" the mapped device when finished creating the encrypted partition.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: 19ba8f45e3d3d7bf348103cee5a0eeaa
CheckboxSystem: 099634613a96bc3665b92c4a813055e8
Date: Tue Nov 17 15:37:09 2009
DistroRelease: Ubuntu 9.10
Package: cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
SourcePackage: cryptsetup
Uname: Linux 2.6.31-12-generic i686

See original description
Revision history for this message
komputes (komputes) wrote :
Revision history for this message
komputes (komputes) wrote : apport-collect data

Architecture: i386
CheckboxSubmission: 19ba8f45e3d3d7bf348103cee5a0eeaa
CheckboxSystem: 099634613a96bc3665b92c4a813055e8
DistroRelease: Ubuntu 9.10
Package: palimsest (not installed)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 LANGUAGE=
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
Uname: Linux 2.6.31-12-generic i686
UserGroups: adm admin cdrom dialout fuse lpadmin plugdev sambashare

Revision history for this message
komputes (komputes) wrote : XsessionErrors.txt
tags: added: apport-collected
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Setting to Confirmed, Medium.
From : https://wiki.ubuntu.com/Bugs/Importance

Medium: most bugs are of medium importance, examples are:
    * A bug that has a moderate impact on a core application.
    * A bug that has a severe impact on a non-core application.
    * A problem with a non-essential hardware component (network card, camera, webcam, music player, sound card, power management feature, printer, etc.)

Changed in gnome-disk-utility (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Steve Langasek (vorlon)
Changed in cryptsetup (Ubuntu):
status: New → Invalid
James (jneethling)
Changed in gnome-disk-utility (Ubuntu):
status: Confirmed → Fix Released
status: Fix Released → Confirmed
Revision history for this message
Robin Roth (robinro) wrote :

The problem is only partially solved by making "Disk Utility" close the luks device.

In fact all other situations in which a device is not closed correctly also lead to this error.
I use an encrypted external harddrive. Whenever I shutdown the drive before unmounting or suspend the pc, then disconnect the drive and resume the pc, the luks device is not closed cleanly. Such situations can happen and should be handeled correctly, by making nautilus (or the gvfs backend, I'm not an expert here) close a luks drive automatically, when it is no longer accessible.

Steps to reproduce:
1) mount an luks-encrypted external harddrive
2) suspend the system
3) disconnect the drive
4) resume the system
5) connect the drive
6) try to mount the encryptet partition (happens automatically by default when inserted)

I would be happy to give further details when helpful and will test a patch if available.

Revision history for this message
In , Saikat (saikat-redhat-bugs) wrote :

Steps to reproduce:
1) Insert a USB stick with an encrypted partition
3) Pull out the USB stick
4) Intert the USB stick again

Result:
GNOME displays a dialog for the password. Once submitted, the following error comes up:
Error unlocking device: cryptsetup exited with exit code 239: Command failed: Device already exists

This is due to the mapping being Opened when the stick is first inserted, but never closed, which creates a conflict.

Workaround:
Do the following to resolve the conflict of the existing device in /dev/mapper.
$ ls -al /dev/mapper
(Identify the mount point for your drive, "sudo blkid" may help)
$ sudo cryptsetup luksClose devkit-disks-luks-uuid-<uuid>-uid1000

What is expected:
Someone (e.g. cryptsetup) should "cryptsetup luksClose" when it detects an old mapped device can no longer be accessed (perhaps in response to the same device being plugged in again).

Revision history for this message
In , Milan (milan-redhat-bugs) wrote :

Well, the problem is exacltly defined.

But if devkit-disks/udisks create the mapping in reaction of inserting device event, it should also handle removal of device.

Maybe I can add some --force option to cryptsetup, which remove all existing (or dead) crypt mapping of previous instance of newly appeared device.

But cryptsetup cannot handle
- force unmounting possible FS (it is another level, cryptsetup have no idea about FS)
- trigger any event on device removal (cryptsetup is just binary to create mapping, someone must add some rule which run it - here udisks I guess?)

I am reassigning this to udisks, but there is probably some part where cryptsetup can help, not sure. Please let me know if you have such request...

Revision history for this message
In , Till (till-redhat-bugs) wrote :

pam_mount contains a helper program to cleanly mount/umount luks devices. Maybe you can use it for udisk, too. E.g. mount /dev/foo /mnt/foo will open it and ask for a passphrase, umount /mnt/foo will umount it and close the cryptsetup device if pam_mount is installed.

Revision history for this message
In , David (david-redhat-bugs) wrote :

(In reply to comment #1)
> Well, the problem is exacltly defined.
>
> But if devkit-disks/udisks create the mapping in reaction of inserting device
> event, it should also handle removal of device.

Right - I thought we already handled the force_unmount + luks_teardown but perhaps it broke some time ago. Anyway, the general problem is tracked here

 http://bugs.freedesktop.org/show_bug.cgi?id=24279

and it asks to automatically Do The Right Thing(tm) for devices set up via udisks (and only for devices set up via udisks).

(And if I've learned anything the past half decade where I've been working on these things... is that it can be very dangerous to automatically do things like this (the same way that it's very dangerous to automount and autoassemble based on signatures). So that's why I'm keen on automatically cleaning up only after things set up via udisks.)

> Maybe I can add some --force option to cryptsetup, which remove all existing
> (or dead) crypt mapping of previous instance of newly appeared device.
>
> But cryptsetup cannot handle
> - force unmounting possible FS (it is another level, cryptsetup have no idea
> about FS)
> - trigger any event on device removal (cryptsetup is just binary to create
> mapping, someone must add some rule which run it - here udisks I guess?)
>
> I am reassigning this to udisks, but there is probably some part where
> cryptsetup can help, not sure. Please let me know if you have such request...

I think it's probably wrong to make cryptsetup, mount, mdadm, lvm etc. worry about this - such cleaning up is generally considered "policy".

Revision history for this message
komputes (komputes) wrote :

I just has the same issue using a LUKS encrypted USB drive (created in Karmic) on a Lucid beta LiveCD session.

Unfortunately the workaround in the description no longer works for me.

Revision history for this message
komputes (komputes) wrote :

$ sudo cryptsetup luksClose devkit-disks-luks-uuid-35df8717-0b13-45e6-9cfc-71d2cad4fd4d-uid1000
Command failed: Device busy

(Have tried this when the drive was unmounted)
$ sudo cryptsetup luksClose devkit-disks-luks-uuid-35df8717-0b13-45e6-9cfc-71d2cad4fd4d-uid1000
Command failed

Revision history for this message
Pete Phillips (pete-smtl) wrote :

unsatisfactory workaround to do the whole thing manually.

NOTE: assumes that your external LUKS encrypted drive is mounted as /dev/sdb1 and the device name in /dev/mapper is wdcrypt. Change these for your own situation.

Create 2 scripts - mount-luks and unmount-luks (or umount-luks if you are a purest!) as below, and make executable. This also assumes you have something like:

   /dev/mapper/wdcrypt /mnt/wdcrypt ext3 user,atime,noauto,rw,dev,exec,owner

in /etc/fstab.

Run the mount-luks script, and you get prompted for a password, then the disk gets mounted. unmount-luks umounts it so you can unplug it. Not exactly seamless but as an interim measure it's OK.

::::::::::::::
/home/pete/bin/mount-luks
::::::::::::::
#!/bin/sh

# mount encrypted external USB WD drive
# ASSUMES plugged in disk is /dev/sdb1!!

sudo cryptsetup luksOpen /dev/sdb1 wdcrypt
mount /mnt/wdcrypt

::::::::::::::
/home/pete/bin/unmount-luks
::::::::::::::
#!/bin/sh

# unmount encrypted external USB WD drive
# ASSUMES plugged in disk is /dev/sdb1!!

umount /mnt/wdcrypt
sudo cryptsetup luksClose wdcrypt

Revision history for this message
Tien Nguyen (tienhn) wrote :

I got the same problem on Lucid.

Revision history for this message
Steve Conklin (sconklin) wrote :

It appears that this may be fixed in the upstream cryptsetup

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574126

Revision history for this message
Steve Langasek (vorlon) wrote :

cryptsetup 1.1.2 has been merged into maverick - can anyone confirm this is fixed there?

Revision history for this message
Ubuntu MOB (ubuntu-mob-com) wrote :

Ubuntu Maverick Alpha 2
cryptsetup 1.1.2

Problem still exists.

Revision history for this message
Cerin (chrisspen) wrote :

Does anyone have a current workaround? None posted here work. This bug should be marked criticial as it makes encrypted drives unusable on Ubuntu.

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

komputes (komputes)
description: updated
komputes (komputes)
description: updated
Revision history for this message
Robbie Williamson (robbiew) wrote :

so based on comment #12, the problem is either with gnome-disk-utility or not fixed in the latest cryptsetup. Will target to lucid and maverick, but still needs investigation into finding the right solution.

Changed in gnome-disk-utility (Ubuntu Lucid):
status: New → Confirmed
status: Confirmed → New
Changed in cryptsetup (Ubuntu Maverick):
status: Invalid → New
Robbie Williamson (robbiew)
Changed in gnome-disk-utility (Ubuntu Lucid):
importance: Undecided → Medium
Revision history for this message
komputes (komputes) wrote :

I beleive that one solution would be to have palimpsest lock the encrypted drive after creating it. This way it could be ejected any number of ways (palimpsest, nautilus, etc...) without the mapper point still existing.

Revision history for this message
komputes (komputes) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

> 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.

There is no graphical frontend that's part of cryptsetup.

Revision history for this message
In , Tim (tim-redhat-bugs) wrote :

A workaround for when luksClose fails: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554600#25

Revision history for this message
In , Milan (milan-redhat-bugs) wrote :

(In reply to comment #5)
> A workaround for when luksClose fails:

All <F12 .. rawhide> have fixed cryptsetup already in updtes, no workarounds for luksClose needed.

Revision history for this message
In , Mathieu Trudel-Lapierre (cyphermox) wrote :

As reported in Launchpad here: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/gnome-disk-utility/+bug/484429

It seems that udisks doesn't tear down cleartext LUKS devices when its slave is forcibly removed, for example, by unplugging a USB drive which holds a LUKS-encrypted partition.

Re-inserting the device then yields the usual password prompt to decrypt the device, but fails to load it with a cryptsetup error:

Error unlocking device: cryptsetup exited with exit code 239: Device udisks-luks-uuid-7bdbda08-473f-41eb-9837-88a4285b1c05-uid1000 already exists.

Revision history for this message
In , Mathieu Trudel-Lapierre (cyphermox) wrote :

Created an attachment (id=38888)
use luks_holder property to identify luks cleartext device

It seems that using device->priv->luks_holder for the device that is being remove still contains the name of the cleartext LUKS device that requires that slave, so it's possible to use it to immediately get which device to use for force_luks_teardown().

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I can't reproduce this issue on my system unless I forcibly remove the device (or suspend as commented by komputes), on the other hand, it happens as well in nautilus, which leads me to believe the issue lies in udisks rather than cryptsetup or elsewhere.

I can also see that udisks doesn't seem (to me at least) to do things right, searching through all devices' properties to look for the one that has the removed device as slave, when these properties have already been updated and removed.

Since I was able to write a patch that seems to me like it's fixing the issue for both use cases (nautilus/palimpsest and suspend), I'm adding a task for udisks (and I pushed the patch upstream for review).

Revision history for this message
In , Mathieu Trudel-Lapierre (cyphermox) wrote :

Created an attachment (id=38904)
updated patch

udisks would segfault if the device was ejected from Nautilus... this is because luks_holder is NULL in that case.

Martin Pitt (pitti)
Changed in gnome-disk-utility (Ubuntu Maverick):
status: Confirmed → Invalid
Changed in gnome-disk-utility (Ubuntu Lucid):
status: New → Invalid
Changed in udisks (Ubuntu Maverick):
assignee: nobody → Martin Pitt (pitti)
status: New → In Progress
Revision history for this message
In , Martin Pitt (pitti) wrote :

I can reproduce this bug.

Revision history for this message
In , Martin Pitt (pitti) wrote :

Thanks! This patch makes a sense, and I confirm that it now behaves correctly with both regular unmount and yanking out a mounted encrypted USB stick. Pushed to git master.

I'll try to write a test case for this, too.

Revision history for this message
Martin Pitt (pitti) wrote :

Pushed to upstream git head, thanks Mathieu!

Changed in udisks (Ubuntu Maverick):
status: In Progress → Fix Committed
Revision history for this message
In , Martin (martin-redhat-bugs) wrote :

This just got fixed in udisks git trunk:

http://cgit.freedesktop.org/udisks/commit/?id=16529b69f7b1ab33e2b92f99cc3bef17d6f20a25

Revision history for this message
Martin Pitt (pitti) wrote :

Uploaded into maverick review queue.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udisks - 1.0.1+git20100614-3

---------------
udisks (1.0.1+git20100614-3) unstable; urgency=low

  * Add 00git-fix-luks-forced-removal.patch: In the event of the forced
    removal of a crypto device, use the luks_holder property since it is still
    available to figure out which underlying cleartext LUKS device to
    teardown, instead of scanning through all available devices (because the
    cleartext device already has had its properties cleaned up). Many thanks
    to Mathieu Trudel for the patch! Patch cherrypicked from upstream git
    trunk. (LP: #484429)
 -- Martin Pitt <email address hidden> Mon, 27 Sep 2010 18:56:00 +0200

Changed in udisks (Ubuntu Maverick):
status: Fix Committed → Fix Released
Revision history for this message
komputes (komputes) wrote :

Mathieu's patch fixes the error message in most scenarios:
- Ejecting device from palimsest without locking
- Pulling out device without warning the OS (unsafe)
- Suspend, Resume

However I found that it did not work for me in the following scenario (received same error):
- Suspend, Pull Out, Resume

Revision history for this message
komputes (komputes) wrote :

In fact, while sleeping, I pulled out the disk, on return, the disk is still there, and I can copy stuff to disk for a while before it realizes the disk is not there. When it realizes the disk is no longer available, it gives the following error:

Method "DriveEject" with signature "as" on interface "org.freedesktop.UDisks.Device" doesn't exist.

Revision history for this message
Martin Pitt (pitti) wrote :

komputes,

this sounds like a more general problem, though -- I bet you can also reproduce this with normal unencrypted USB sticks. Anyway, I think it's worth filing a new bug about it. I guess what happens is that nothing checks the state of USB devices after resuming, and thus there is never a "remove" event for the device. This requires some more thorough discussion what the right solution is.

Bug Watch Updater (bug-watch-updater)
Changed in udisks:
importance: Unknown → Medium
status: Unknown → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in udisks:
importance: Medium → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in udisks:
importance: Unknown → Medium
Launchpad Janitor (janitor)
Changed in cryptsetup (Ubuntu Lucid):
status: New → Confirmed
Changed in cryptsetup (Ubuntu Maverick):
status: New → Confirmed
Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Changed in udisks (Ubuntu Lucid):
status: New → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in cryptsetup (Debian):
status: Unknown → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

00git-fix-luks-forced-removal.patch does not apply to the lucid sources. Will some kind soul please backport the patch so we can get an SRU for lucid?

Revision history for this message
tankdriver (stoneraider-deactivatedaccount) wrote :

I can reproduce this bug in oneiric beta2 after unsafe remove of encrypted drive.

Revision history for this message
Martin Pitt (pitti) wrote :

I can't reproduce this in oneiric. Can you please give the output of "dmesg", "udisks --dump", and "udevadm info --export-db" after ripping out the USB stick?

Revision history for this message
airtonix (airtonix-gmail) wrote :

I created an excrypted sdcard with palimpset.

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) Remove sdcard
5) On resume, no errors
6) Insert encrypted sdcard from step 4)
7) Prompted to enter password for device.
8) "Error unlocking device: cryptsetup exited with exit code 239" error is shown.
9) sdcard is never mounted.

Revision history for this message
airtonix (airtonix-gmail) wrote :

just adding that #33 is on 11.10 64bit with gnome-shell

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
dmesg output after plugging in sdcard, entering password, recieving error

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
udisk dump output after plugging in sdcard, entering password, recieving error

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
udevadm output after plugging in sdcard, entering password, recieving error

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
dmesg output after pulling out sdcard

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
udevadm output after pulling out sdcard

Revision history for this message
airtonix (airtonix-gmail) wrote :

ubuntu 11.10 64bit, system76 serval laptop.
udisk output after pulling out sdcard

Revision history for this message
Karl Maier (w-wall2001) wrote :

I can reproduce the behavior on Ubuntu 11.10 (Natty) 64bit with the following steps:

1) connect a luks-encrypted external harddrive and mount it
2) disconnect the drive
3) connect the drive
4) try to mount the encrypted partition again (happens automatically by default when inserted)

Revision history for this message
In , Manuel (manuel-redhat-bugs) wrote :

Same problem here in Fedora 16 (Fresh install). Seems the bug got implemented again.

Probably...
"It's not a bug, it's a feature!" :)

Revision history for this message
In , Bugra (bugra-redhat-bugs) wrote :

got the same issue on F16 with removable HD.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Revision history for this message
unksi (unksi) wrote :

This bug still exists with at least Ubuntu 13.04 and Ubuntu 13.10.

tags: added: raring saucy
Rolf Leggewie (r0lf)
Changed in cryptsetup (Ubuntu Maverick):
status: Confirmed → Won't Fix
Alberto Salvia Novella (es20490446e)
Changed in cryptsetup (Ubuntu):
importance: Undecided → Medium
Changed in udisks (Ubuntu):
importance: Undecided → Medium
Changed in cryptsetup (Ubuntu Lucid):
importance: Undecided → Medium
Changed in cryptsetup (Ubuntu Maverick):
importance: Undecided → Medium
Changed in udisks (Ubuntu Lucid):
importance: Undecided → Medium
Changed in udisks (Ubuntu Maverick):
importance: Undecided → Medium
Revision history for this message
Vincent Hindriksen (vhindriksen) wrote :

For the work-around: "sudo cryptsetup luksClose <luks-id>" works when you close all shells and editors which were working on a file or path on the LUKS-drive.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

I still experience this problem in trusty when

1) mount encrypted USB disk
2) suspend
3) unplug USB disk
4) wake up
5) plug in USB disk
6) try to mount again and answer the password prompt

tags: added: trusty
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in cryptsetup (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in udisks (Ubuntu Lucid):
status: Confirmed → Won't Fix
Revision history for this message
UBUCATZ (ubucatz) wrote :

This problem still exists in trusty.

after suspend / resume an external excrypted harddrive automaint fails with this error.

How to solve this totally annoying behaviour?

Also I would like to know: how can I make the automount mechanism forget the password?

Revision history for this message
UBUCATZ (ubucatz) wrote :

BTW this error seems to be triggered by the password input mechanism - when I save the luks password "forever", volume management will always remount that enrypted device without trouble after resume.

The two other options ("forget immediately" and "forget when log out") lead to the described problem with cryptsetup failing with a "device already exists".

Revision history for this message
Mike McNally (emmecinque) wrote :

For what it's worth, I'm seeing this exact problem in 15.04.

Revision history for this message
Jan Smith (johsmi9933) wrote :

I am having this problem using 15.10. May be related to trying to mount an encrypted external harddisk after the computer was suspended.
6 years after this bug has been opened it is still affecting people.

Revision history for this message
Jan Smith (johsmi9933) wrote :

This error is making using encrypted external USB harddrives completely unusable for me. I see that error every time I try to use any (of two completely different) devices after a few minutes, sometimes after a bit longer.

There are suggestions on help pages to use "sudo dmsetup remove /dev/mapper/udisks-luks-uuid-xxxx" however this fails with a "device busy" message.

There are suggestions on help pages to use "sudo cryptsetup luksClose udisks-luks-uuid-xxxxx" however this also failes with a "Device or resource busy message".

The only temporary way to make this error message go away is to completely reboot my computer, reattach the harddrive, enter the password and use it for a few minutes until the same error appears again.

I am using Ubuntu 15.10 4.2.0-35-generic #40-Ubuntu SMP Tue Mar 15 22:15:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Bug Watch Updater (bug-watch-updater)
Changed in udisks (Fedora):
importance: Unknown → Medium
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.