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
