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.
Category: administration Page 1 of 2
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
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
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
The moral of the whole story, better use
visudo when editing
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.
For a long time now I run an AWS Lightsail VPS serving as a wireguard gateway to my home server. Since recently connecting to the Lightsail instance via wireguard is no longer possible.
When I took a look with SSH I got
$> sudo wg-quick up wg0 [#] ip link add wg0 type wireguard RTNETLINK answers: Operation not supported Unable to access interface: Protocol not supported [#] ip link delete dev wg0 Cannot find device "wg0"
To be sure I updated all packages, but the problem still persisted.
The port used by wireguard had not changed and still was accessible according to the network settings of Lightsail.
What change in the Lightsail VPS or network settings could cause an issue like this? It literally just stopped working over night.
This is a very brief article or rather a reminder to myself, about how to install MiniDLNA on Ubuntu Server 20.04. I always knew this piece of software by it’s old name MiniDLNA, but apparently it was renamed and is now called ReadyMedia. There don’t seem to be many changes below the hood though.
MiniDLNA is a light-weight media server using the DLNA protocol. Through MiniDLNA a library of media files is created which allows a user to very conveniently browse through the files and start audio and video playback. Most SmartTVs and Android phones support DLNA out of the box.
It is sometimes desirable to bring a Wireguard interface up each time the system boots. Using
wg-quick it is dead easy to create a service which takes care of the required steps. In case wg0 is already up and running, it must be taken down before the service can start successfully.
$> sudo systemctl enable firstname.lastname@example.org $> sudo systemctl daemon-reload $> sudo wg-quick down wg0 $> sudo systemctl start wg-quick@wg0
Since Windows 10 version 1709 (“Fall Creators Update”) neither SMB1 nor NetBios device discovery is supported anymore.
Due to this change a Samba share which is hosted on a Linux machine may no longer show up in the Network view of Windows Explorer.
Although the Samba share can still be reached by it’s hostname or IP address (and share name) this is a slight inconvenience.
Luckily there is a small Python tool called wsdd which provides a Web Service Discovery (host) daemon. What follows is a short guide on how to install and use wsdd on Ubuntu Server 20.04 (works similar for other Debian based distributions).
Recently I migrated my home NAS from OpenMediaVault to Ubuntu Server.
The reason for this was some major issues after upgrading from OMV4 to OMV5. After spending a lot of time to figure out what’s wrong with my NAS after the upgrade, I figured that the main advantage of using OMV (less maintenance) had become an disappointment. So the decision to migrate to Ubuntu Server was made.
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.