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: linux 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 /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.
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 wg-quick@wg0.service $> sudo systemctl daemon-reload $> sudo wg-quick down wg0 $> sudo systemctl start wg-quick@wg0
References:
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.
Wireguard is a modern VPN protocol allowing secure and confidential communication between a network of peers. Wireguard is based on the concept of private-public key cryptography and a number of other modern cryptographic algorithms. Have a look at the wireguard white paper for more details.
Wireguard Requirements
Since Linux kernel version 5.6 (late March 2020) wireguard is an integral part of the Linux kernel. That means Linux distributions using a kernel >= 5.6 do not need to install any additional packages in order to support wireguard.
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/
