I lost access to my encrypted drives. Here is how it happened. After setting up my NAS using full-disk encryption on both disks, I had the nagging feeling of not remembering the passphrase I chose or the keyfile I used. At this point I should have just read my previous blog post because the main reason I am writing these things down is to document them. It would have told me that I used a keyfile and not a passphrase. Since at this point my disks were still unlocked, I might have been able to add another key slot with a passphrase or another keyfile. Instead I saw that the OpenMediaVault encryption plugin has a button ’test’ to test the passphrase or keyfile. I made use of it, and tested my usual passphrase. It returned successfully. So at this point I thought I knew how to unlock my disks. Until the system rebooted and would not accept my passphrase anymore.

Digging deeper, it turned out that the OpenMediaVault test button has a bug and would always return ’success’ if the passphrase contains a ’space’ character, which mine incidentally did. After all it is that space that turns a password into a passphrase, right? I dutifully reported the issue on GitHub and it was confirmed by the author. Yet I still lost access to all my data. Luckily, I had backups of everything and suffered no data lost.

So I am now left with having to setup my NAS again and I decided to make some changes. I do not like graphical user interfaces and in the few month using it, I also did not particularly enjoy the user interface of OpenMediaVault. As it turn out, it is just a wrapper around underlying UNIX tools tied together with a database. And as the story above shows, this wrapper can lead to additional bugs not present in the actual tool. That is bound to be the case with all wrappers, and I do not blame the OpenMediaVault authors. For the second setup I decided to forgo OpenMediaVault and just setup and use the underlying tools. I stumbled upon Ansible which would make this process easier and more importantly, reproducible. Ansible is a configuration management and deployment orchestration tool. It is meant to setup many different machines to the exact same state. In this regard it is a bit overkill for the application of setting up a single NAS. But I enjoy scripting and text as a user interface and the Ansible Galaxy provides tons of premade ’playbooks’ and ’roles’ that only need to be customized. After getting to grips with Ansible itself (it is the first time I am using it), I could reuse many components, especially from the excellent debops project. The encryption role debops.cryptsetup generated the encryption keyfiles localls and also made a backup of the LUKS headers. So hopefully, I will not lock myself out of my data again. Only for snapraid could I not find anything adequate and wrote my own role, which took much inspiration from the existing one from IronicBadger.

Here is the playbook to setup the NAS using 2 encrypted drives with snapraid:

---
- hosts: nas
  become: true
  pre_tasks:
    - name: install necessary packages
      apt:
        name: 
          - cryptsetup 
          - xfsprogs
          - libuser
          - git
        update_cache: yes
  roles:
    - debops.secret
    - debops.cryptsetup
    - debops.users
    - debops.mount
    - samd.snapraid

In theory, I can now setup any number of NAS the exact same way. Should my setup ever crash (e.g. by memory card corruption), I can put it back into the same state. To turn it into a full OpenMediaVault replacement, I still need to add services to share the data and monitoring, which I will do soon. This switch also allowed my to move to Armbian based on the new Debain buster, which was not possible with OpenMediaVault as OMV5 is still beta and OMV4 is based on debian stretch. By the way, I was not the first to think about using Ansible for NAS setup, see here for inspiration.