Encrypted flash drives
Hello the list!
This is a problem of repairing an encrypted USB drive that isn't playing
nice with Gnome after setup although it is basically working and no data
has been lost.
Today I opened my desk drawer and found the USB flash drive I have used
to back up my GPG private keys, revokation keys etc had _something
sticky_ growing on it. Not nice. And bizarre because nothing around it
in the drawer was affected.
So I bought 2 identical relatively small new USB drives, with the intent
of copying the content of the
rapidly-becoming-unfit-for-human-consumption drive onto both of them,
and keeping one offsite. And this seemed like a great time to make my
first experiment with volume encryption.
I'm running Jessie and Gnome on the desktop, so my machine's default
behaviour when I plug in a flash drive is to pop up a, erm, pop-up
asking if I want to open the drive in Files (nautilus) or eject it. I
clicked Open with Files. Next I right-clicked on the drive in the left
pane and chose "Format..." To my rather pleasant surprise support for
encrypting the volume was right there in the Format dialog. I proceeded
to provide a label and passphrase for the drive and went through the
confirmation stages warning me I was about to lose data and so on.
Then, nothing apparently happened. Turns out it was creating the ext4
file system in the just-created encypted volume, but it didn't _say_
that, and I thought it was done, and had unmounted the volume, so I
removed it. D'oh!
I've filed a bug on Files for that because although I was stupid to
remove the device without doing SOMETHING to check if it was still being
used, the fact is Files gave me zero feedback that it was doing
anything.
After this Files couldn't do anything with the drive so I dropped to the
command line. There I executed the following as root:
cryptsetup luksFormat /dev/sdg1
(for 'twas /dev/sdg1 where the now-messed-up drive was). This completed
successfully, asking me for the passphrase on the way. Then:
cryptsetup luksOpen /dev/sdg1 SECRETKEY1
Which also completed successfully. Finally:
mkfs.ext4 /dev/mapper/SECRETKEY1
which took a bit longer to complete than I expected, but eventually
completed successfully. That was what tipped me off to what I had done
wrong in the first place in Files.
After this, I ejected the device, and plugged it back in. Gnome does not
respond, but if you manually start Files, you can see "8.1GB Encypted"
in the left hand pane. Clicking on that triggers the request to supply
the password and on correctly supplying the password you have access to
the device. However, can't write to it, and I have to drop to the
command line and su to root before I can do so.
I then used Files to format and encrypt the second device, and this time
was more patient to wait until it was finished, at which point the
device was mounted with the label I'd chosen and I could safely eject it
the normal way. After this, re-inserting the second device is
automatically detected by Gnome and I am prompted for the password, and
on supplying it, I get the usual "Open in Files or Eject" prompt and
everything operates after that as if it were not encrypted, including
non-root writes.
With both drives mounted, I compared the /etc/mtab entries for the two
and this is what I found:
/dev/mapper/luks-378947be-2ef0-452e-8d80-04064aec5bc7 /media/mark/138b9d59-b0cd-49cc-a738-8fecea5f0035 ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
(that's the first drive, that I used the command line to fix after
messing it up in Files)
/dev/mapper/luks-0dfd326a-10ea-4f1f-8ca3-4ab492ebd62e /media/mark/SECRETKEY2 ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
(That's the second one that everything works properly for).
>From here, how can I fix the first one to play nice? (Wiping it and
re-formating from scratch is an option, but I figure I will learn more
from fixing it)
Thanks!
Mark
Reply to: