Auto mount NFS shares on Raspbian

I’m using influxdb on my Raspberry Pi in combination with a NFS mount. The NFS mount is on my Synology NAS and should store the database data of influxdb. Reason for this setup is that I fear that the SD card won’t survive the many write/read cycles caused by a database writing to it.

The shared folder on my Synology is configured to be accessible by various IPs in my network:

The problem with Raspbian is that I’ve tried to auto mount the NFS share on startup, so that the influxdb service can directly write to the NFS mount. 

I’ve used these settings in my /etc/fstab to mount the volume automatically:

<DS IP>:/volume1/databases /mnt/databases nfs auto,user,rw,nolock,nosuid 0 0

This doesn’t work properly since my influxdb is often dead after a restart, but if I check the mounted volumes I see the NFS volume mounted properly.

However, there’s a tool called autofs which already helped me with a similar problem on my Mac when I moved my iTunes library to the Synology share.

Install autofs using

sudo apt-get install autofs

Open the file /etc/auto.master and add something like this

/mnt    /etc/auto.databases     -nosuid,noowners

Now create a file called /etc/auto.databases with this content

databases       -fstype=nfs,user,nolock,nosuid,rw <DS IP>:/volume1/databases

Unmount the existing NFS share. Remove/comment out the line for the nfs mount in your /etc/fstab so that it doesn’t conflict with autofs. Restart autofs with

sudo service autofs restart

Now check the content of your mount point with e.g.

ls /mnt/databases

Autofs should now automatically mount the NFS share. This might take a while, which is a good sign that the mount is loaded. You can also verify with

mount

that your NFS share is mounted to e.g. /mnt/databases. If you’ll restart now, influxdb should be happy on restart. When it tries to start, autofs will see the access to the mounted folder and will mount the NFS share before influxdb can start up properly.

Configure influxDB to store its data in a different folder

The default location of the influxDB data is /var/lib/influxdb. If you want to change the location, you’ll need to configure three folders to be in a different place. The changes should be done in the file /etc/influxdb/influxdb.conf

...
[meta]
  # Where the metadata/raft database is stored
  #dir = "/var/lib/influxdb/meta"
  dir = "/mnt/databases/influxdb/meta"
...
[data]
  # The directory where the TSM storage engine stores TSM files.
  #dir = "/var/lib/influxdb/data"
  dir = "/mnt/databases/influxdb/data"

  # The directory where the TSM storage engine stores WAL files.
  #wal-dir = "/var/lib/influxdb/wal"
  wal-dir = "/mnt/databases/influxdb/wal"

I’m using this to store the data on a NFS share which is mounted automatically. If you want to keep your existing data, move the existing content of /var/lib/influxdb to the new location.

Make sure, that the new location is owned by influxdb user and group.

Improve OpenVPN security on Synology DiskStations

I’m using OpenVPN on my Synology DiskStation with certificates instead of Preshared Keys. A few days ago I’ve wanted to login to my VPN and it wasn’t working. After checking the log file I’ve seen that there were some issues with the used configuration file for OpenVPN.

Tue Nov 20 23:04:27 2018 Cipher algorithm 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CB' not found
Tue Nov 20 23:04:27 2018 Exiting due to fatal error

How can this be? The configuration worked for months without problems? I’ve started to remember that I’ve started to increase the security of my OpenVPN configuration using a few parameters. The Cipher algorithm is one of them. This page describes some of the changes I’ve made (unfortunately only in German).

I’ve added the tls-cipher and tls-auth options as last parameter lines to my configuration file. The synology web UI tried to parse those parameters as cipher and auth parameter when it shows those values as part of the DSM UI.

I’ve reorderded the tls-auth and tls-cipher parameter to be above the auth and cipher parameters and the DSM UI is now able to show those values correct. This will enable you to restart the OpenVPN service from the WebUI without the need to login via SSH.

How do you get supported values for auth, cipher and tls-cipher you might wonder? Just execute

openvpn --show-tls

to get the supported tls-cipher you might line up with a : separated.

openvpn --show-digests

shows you the allowed values for auth and

openvpn --show-ciphers

will show the allowed values for cipher. However, cipher and auth can also be preselected from the DSM UI.

Don’t forget to use the same values in your OpenVPN configuration on your VPN client as well, otherwise the connection won’t work.

Slow SMB transfers in Mac OS 10.12.2

I’m using a 802.11ac WLAN to connect to my Synology NAS. With the last Mac OS 10.12.2 update the network performance was catastrophic when I tried to access the NAS via SMB. At first I thought this might have been caused by the WLAN connection but even with a Gigabit LAN connection my transfer rates were around 3-5MB/s.

After a short search online, I’ve a few hits describing the actual problem:

Apple uses their own version of SMB and enabled client signing to mitigate against Man in the middel attacks. Therefore all connections underly this signing process and are way slower.

Therefore I’ve disabled client-signing on my mac using this command:

This will write this content

 

to the file /etc/nsmb.conf. After you’ve set this value you need to unmount all samba shares. If you’ll reconnect now, you’ll witness a much better performance, starting with faster loading of network shares.

You can revert this change with

 

Automount network shares on Mac OS for use in iTunes

I’ve moved my iTunes library from my Macbook’s SSD to my Synology NAS on a network share. This is quite easy and can be made inside the iTunes preferences pane. After you’ve changed the path for the iTunes Media, all iTunes managed media will be moved to the new location (assuming you let iTunes manage your files of course :)).

This allows you to have your iTunes library on your Macbook while all the large files are stored on the NAS. This is especially important for larger libraries as well as the newer Macbooks which only have a limited flash drive instead of larger harddisks.

However, there is one important problem with this solution: Once you’ve disconnected from this network share for whatever reasons and you try to start iTunes, you’ll have your iTunes Media folder reset to your user’s music folder on your boot disk. You’ll now need to reset the path to your files again, and this will again cause iTunes to check all files if they are on the right location and moves them if necessary.

I thought I’ve taken care of this problem with auto connecting to the network share with a Login Item. However, this didn’t help me much since I sometimes have disconnections to my network (e.g. when I’m on the road) and the network connection will only be created once during the login of your current user. So this doesn’t help me at all and caused me to look for another better solution.

So I’ve found this gist (the link is dead) and modified it a little bit to my environment. Therefore here’s my short list of modifications for using autofs in combination with AFP or SMB volumes:

If you now start up iTunes again, it will try to locate the media files in the /Volumes/music folder, like I manually specified it. However, autofs will now automatically mount the network share for me and iTunes won’t complain about a missing volume. This way I won’t ever need to take care of manually updating the path once I forgot connecting to my NAS 🙂

Update:
Hm, it seems that the trick with /../Volumes does not work anymore on Mac OS 10.11.4 🙁 If I try to list the content of the mounted volume an error message is returned:

ls: : Unknown error: 118

So I need to mount the volume in a different folder and need to change the path in iTunes again.

Update 2:
I’m not able to mount afp volumes anymore so I’m using smbfs like it is described here. However, this will require a user and password in the configuration file 🙁

Update 3:

Mac OS Sierra breaks the autofs configuration. I had to change it a little bit according to this SuperUser entry. The Gist is updated accordingly.

Update 4:

This still works on Mac OS High Sierra. However, make sure that you enter the credentials correctly and that you spare special characters, according to this blog:

Note: If you have a password longer than 8 characters, or if the password has special characters in it (like “! # $ % & ‘ ( ) * + , – . / : ; & < = > ? @ [ \ ] ^ _ { | } ~”), you may receive a “No locks available” error message and the share will not mount under /home. You will also receive a “No locks available” or similar “Host is down” error if the password is wrong or missing.

I’ve encountered the „No locks available“ today and had an error in my password which blocked the auto mounter from opening the folder.