On my NAS server I use Snapraid to protect against data loss and to some extent data rott. I do backups too, but only about once a month and when all the stars align. Automatically and regularly scrubbing a Snapraid array is well advised to keep that data save.
Tag: administration
I had the unfortunate experience to lock myself out from using sudo on my NAS server.
All I wanted to do was give my user permission to run smartctl, which usually requires root privileges. This can be achieved by editing the /etc/sudoers file.
However I did not use visudo for this task. After removing the pound sign from the #include statement – which, let’s be honest, looks like a comment that needs to be uncommented – I saved the file and closed it.
At this moment visudo would have raised an error, if I had used it, and prevented me from saving the invalid sudoers file.
Long story short I was locked out from using the sudo command. After booting into a Linux live/rescue image from USB I could fix the syntax error in /etc/sudoers.
The moral of the whole story, better use visudo when editing /etc/sudoers.
That’s it.
References:
At some point we all want to store Docker images and volumes on a different drive, to avoid the system drive being filled up as the volumes grow. Here’s how.
So my OpenMediaVault (OMV) NAS did reboot today for some reason. It didn’t manage to boot up successfully again, however, but entered “emergency mode” instead.
After some digging around it seems this is related to the combination of LUKS drive encryption and MergerFS (same with UnionFS).
For normal operation, first the LUKS drives need to be decrypted. Then the decrypted drives can be pooled together with MergerFS.
Some changes in OMV 5 (as compared to OMV 4) cause the boot sequence to enter emergency mode if not all drives in /etc/fstab can be mounted while booting. Since the LUKS drives are still encrypted when booting, mounting those drives obviously fails. And consequently mounting the MergerFS filesystem also cannot succeed.
The issue can be patched by adding the nofail option to all LUKS drives in /etc/fstab and also adding the noauto option to the MergerFS entry in /etc/fstab. It may only be a matter of time until OMV decides to rewrite /etc/fstab, thus nullifying the changes described above.
But since I do not reboot my NAS that often, the above patch works fine for now.
References:
- https://forum.openmediavault.org/index.php?thread/30129-problem-booting-up-with-luks-and-unionfilesystem/&pageNo=2
- https://forum.openmediavault.org/index.php?thread/33186-omv-5-0-keeps-booting-into-emergency-mode-can-t-ssh-in/
- https://forum.openmediavault.org/index.php?thread/33213-omv-booting-to-emergency-mode/
