Improperly replacing encrypted drive

[ShimadaRiku]

Been testing around with different failure case scenarios before actually going live with my NAS.

FreeNAS 9.3 Stable

I have two SSD in a encrypted mirrored vDev. The proper way to replace a encrypted drive was to first flag the drive as offline so freenas knows it is going to be replaced. Then replace & rekey, but I didn't flag the drive as offline. I took it out and did a secure erase on another PC. The replacement & resliver process went okay and the pool was no longer degraded. But.... I wasn't able to rekey and got this error

Code:

freenas-test manage.py: [middleware.exceptions:38] [MiddlewareError: Unable to set key: [MiddlewareError: Unable to set passphrase on gptid/158dbb74-76d4-11e5-aaac-0800272ce4fb: geli: Cannot open gptid/158dbb74-76d4-11e5-aaac-0800272ce4fb: No such file or directory.

After reading cyberjock's past issues I was able to solve the issue. Because I didn't flag the drive as OFFLINE before replacing, freenas tried to rekey using the old GPTID from the erased ssd. The solution was to manually remove the GPTID from freenas's freenas-v1.db by doing

Code:

sqlite3 /data/freenas-v1.db
select * from storage_encrypteddisk;  

To find the orphan gptid. Then remove doing

Code:

delete from storage_encrypteddisk where id=X;

Where X is the # corrispondindg to the orphaned gptid

After doing so I was able to rekey.

On a side note the Freenas manual said a passphrase must be set before replacing the encrypted drive. Then the passphrase needs to be reset again along with the recovery key. I never used a passphrase and it still worked fine. (for those still confused with how GELI encryption is structed in freenas read this)

 

[cyberjock]

On a side note the Freenas manual said a passphrase must be set before replacing the encrypted drive. Then the passphrase needs to be reset again along with the recovery key. I never used a passphrase and it still worked fine. (for those still confused with how GELI encryption is structed in freenas read this)

Yes, we say that because procedurally you shoudl not be using any zpools that don't have a key+passphrase AND a recovery key. They are replacement for each other in case something happens to one of them and they are invalidated. So you are correct that you did something that disagrees with the manual. But that is because you already did what the manual told you NOT to do. It's like having a double negative. It's effectively your error for not having both keys available, and not an error in the manual.

 

[ShimadaRiku]

It's effectively your error for not having both keys available, and not an error in the manual.

Wasn't saying the manual was in error, but that it was possible; came in light after seeing this thread.

 

[cyberjock]

It's no big deal, so long as you have a backup and take it as a learning experience and go get both keys made. ;)

 

[Spacemarine]

I reported the same problem a few days ago here:

https://forums.freenas.org/index.ph...-from-raidz2-now-im-not-able-to-re-key.38390/

Thanks to your post I finally understand WHAT is going wrong inside freenas. It should be easy to fix I guess.

 

[ShimadaRiku]

I reported the same problem a few days ago here:

https://forums.freenas.org/index.ph...-from-raidz2-now-im-not-able-to-re-key.38390/

Thanks to your post I finally understand WHAT is going wrong inside freenas. It should be easy to fix I guess.

Glad the information was of use to someone. Not many post regarding encryption; other than the mantra of avoid it if possible.

Guess this issue is a bug? https://forums.freenas.org/index.ph...ive-unable-to-set-key-geli-cannot-open.14554/