Volume failed unlocked

[Frederick Flintstone]

I encrypted my disks when I made the volume, and had not had a problem. After a shutdown for home power work, I can no longer unlock my volume, and keep getting this error whenever I attempt it. I have read a previous post concerning detaching and reattaching the volume, but ran into an issue where the volume would not populate on the auto import. I restored from a backup, but still have the same issue.
I have uploaded the debug and the dmesg info as requested.
The data still exists on an old drive, but I would lose some things if I had to rebuild.

Any help would be greatly appreciated.

Thanks!

 

[cyberjock]

The file at /data/geli/<blah blah blah> is missing.

The reason it's missing is because you didn't download the keyfile and are uploading it. Did you download the keyfiles like the manual says to?

If neither your key file or recovery key file are working then the only thing I can say is "you are s.o.l".

If you don't have them, then you are also s.o.l. :(

 

[Frederick Flintstone]

Cyberjock,

First, I appreciate your time in responding. As to the response....

The file at /data/geli/<blah blah blah> is missing.
Where did you get this information? I checked the dmesg, and there was no such entry?

The reason it's missing is because you didn't download the keyfile and are uploading it.
This appears nonsensical to me. If I did not download it, how can I upload it?
I believe you meant to type something to the effect of..."The reason it's missing is because you might not have downloaded the keyfile and are uploading an incorrect file. The correct name for the keyfile is <insert typical file name and extension here>. If you did download the keyfile, try to locate this file and use it when prompted".

Did you download the keyfiles like the manual says to?
I did. IIRC, there were about 3 files I ended up downloading.

If neither your key file or recovery key file are working then the only thing I can say is "you are s.o.l".
I appreciate the technical terminology. I would have preferred something more in the vein of... "If neither your key file or recovery key file are working then the only thing I can say is your data is probably unrecoverable".

I used to respond to people like you did in this response, and found it odd that people insisted in responding negatively to my answers. I now understand why I needed to change the way I communicate with people. For that, I thank you.

 

[cyberjock]

The entry for /data/geli is in your debug file under fndebug/System/dump.txt

Configuring Disk Encryption for gptid/6c88a838-3ed2-11e4-bd9f-6805ca28af3d.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 1 of 3.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 2 of 3.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 3 of 3.
Configuring Disk Encryption for gptid/6ce18c78-3ed2-11e4-bd9f-6805ca28af3d.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 1 of 3.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 2 of 3.
geli: Cannot open keyfile /data/geli/df157c2f-270c-41a7-8e91-1c8afb1de00d.key: No such file or directory.
Attach failed; attempt 3 of 3.

I didn't meant to type anything. I said what I said because that's what I meant (at least in this case ;) ).

When you first create an encrypted pool the key is stored in /data/geli/<id>.key. If you follow the manual it says to download the key and recovery key and store them in a safe place. Once you download the keys they are erased from the boot media. Until you download the keys, on a reboot the pool will automatically mount despite being encrypted because the keys are accessible in /data/geli/<id>.key. In your case, it's attempting to mount the pool during bootup, using keys that shouldn't normally be there during bootup (because a good user would have downloaded the keys), which is the red-flag that you didn't download the keys. Until the keys are downloaded the pool is automatically mounted on bootup. This has the unfortunate situation of giving some users a false sense of security because they don't save the keys and eventually their USB key goes bad and then they have no keys at all.

Then I asked if you downloaded the keys like you were supposed to because there is always the possibility that something is just plain wrong with what I'm remembering or some other scenario is playing out (like you rekeyed the server and didn't download the keys after that) or just some weird AFU bug in FreeNAS. I'm just trying to cover the bases in *case* this isn't the weird screwed up scenario that it looks like. Still other users bootup their FreeNAS box and don't reboot it for months. Just 15 minutes ago I rebooted someone's server that had 150 days of uptime. He also has an encrypted pool and he has to go find his keys (whoops). Unfortunately, too many people store a single copy of their keys on a USB stick. So that one stick goes bad after sitting on a shelf for 150 days and you will find you can never access your data again (whoops). Still others rekeyed their server and forgot to save the new keys after rekeying (whoops). So as you can see, there's plenty of ways to see how this ends very badly for users despite thinking they did everything right.

Lastly, it's all about the "proper pronunciation of the word 'potato' " and there's no correct answer. It's all about personal choices, and we could argue this all day and never see a clear winner.

So let's ask a few more questions:

1. Last time you had to reboot the server and were able to mount the pool, did you have to provide the key or recovery key and password? If not then you didn't have a saved copy.

2. Last time you had to reboot the server and were able to mount the pool, what version of FreeNAS were you using? Was it the same as the version you are currently trying to mount the pool with?

3. What version of FreeNAS was the pool created with (if you remember)?

The answers don't appear to be much help as the current result is that the data is permanently encrypted and there doesn't seem to be a valid decryption key in existence. But, one can hope.

There should have only been 2 key files downloaded (the key and recovery key). The key requires the passphrase to function and the recovery key unlocks the pool without needing a passphrase. So if you have those files I'd try them because they appear to be your only hope. But, if those don't work and you don't have another key hiding somewhere (either on some media elsewhere) or can be pulled off the old boot media then you are probably in a condition where restoring from backups are necessary.